DRY (Don't repeat yourself)

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|719\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> DRY (Don't repeat yourself)
Thu, 19 Feb 2009, 04:14
LostUser	I'm finding time and time again, especially with types I'm constantly having to recode whole elements, and I'm wondering is it possible to do a DRY with Blitz? For example, I'm finding I have to code functions for every type to handle: * getters, setters, find, create type, delete type. IE: Type person field parent.person field name$ End Type Function create_person(name$="") p.person = new person p\parent = null p\name$ = name$ end function Function find... .. end function Function get... ... end function function set... .. end function --v I'm wondering is it not possible to do this instead; // note this doesn't work Type person Field ... ... End Type $v_type = "person" $var = new $v_type --v I hope I've explained the issue. Thanks.
Thu, 19 Feb 2009, 05:01
JL235	For that specific example I'm thinking reflection is what you need. Blitz Basic does not support reflection. You could also do similar if you had inheritence. For example if you have an Infantry and an Archer type and they both have an x and y field then you could define it once in a Unit superclass. Blitz Basic does not support inheritence. If you had polymorphism as well as inheritence then you could also define the getters/setters once, say for the Unit type. The Infantry and Archer types can then automatically use the same function. Blitz Basic does not support polymorphism. My final suggestion is to define things like x,y in their own types that the Infantry and Archer would hold. For example:type Point field x field y end type Type Infantry field location.Point end Type Type Archer field location.Point end Type --v By defining common properties of a type into their own Type objects it helps to make the repeating code in other types smaller. However you can't stop BB from adding the overhead of storing all the Location types in the internal type lists.
Thu, 19 Feb 2009, 06:05
Evil Roy Ferguso	The closest that you can come to this in "classic" Blitz Basic is with the undocumented Object and Handle functions, but it still falls quite short of what you'd like to achieve. Basically, you can use them to stuff a reference to any user-defined type into an integer. markcw has written a tutorial on these functions, as well as other type tricks, that you can read here: https://blitzbasic.com/Community/posts.php?topic=75556 If your types frequently have similar functions, you might also find it worth your time to code a quick program that would generate a "skeleton." This could be as simple as writing out the skeleton with a dummy name, then using Replace() (or equivalent.) Blitz is meant to be a very easy language, and this occasionally makes it harder to use.
Thu, 19 Feb 2009, 06:42
JL235	Evil Roy Ferguson Blitz is meant to be a very easy language, and this occasionally makes it harder to use. I disagree. Blitz is meant to be very simple language, and this occasionally makes it easier to use.
Thu, 19 Feb 2009, 11:46
LostUser	Oh okay. I understand. I was interested in frameworking and wasn't sure if it could handle it. Thanks again.
Thu, 19 Feb 2009, 18:02
Evil Roy Ferguso	JL235 I disagree. Blitz is meant to be very simple language, and this occasionally makes it easier to use. This was meant as a joke, but it's hard to tell on the internet, especially since I seldom use emoticons because my heart is a lump of coal. What I mean by it is that occasionally, Blitz leaves out features that would allow users to write more expressive code (like the templates / reflection that would allow zardon to code as he pleased), if those features would be confusing or complicated to newcomers.
Thu, 19 Feb 2009, 18:17
JL235	@Evil Roy Ferguson: Don't worry, joke or no joke I didn't take it personally or anything. Again it's hard to tell with the internet. Zardon you can simulate some of the aspects of inheritence through wrapping types within types and so build the inheritence tree yourself. For example:type Unit field x field y end type type Infantry field super.Unit end type type Archer field super.Unit end type --v Conceptually both Infantry and Archer are meant to be a subclass of Unit. When new Infantry and Archer types are created you will need to make the new Unit too. I did this recently on a VBScript project and although it worked well it's nothing compared to the real thing.