FEATURE REQUEST: Constructor Arguments
BlitzMax Forums/BlitzMax Programming/FEATURE REQUEST: Constructor Arguments
| ||
| . |
| ||
| Second. |
| ||
| Explain the significant difference between that and factory style creation. |
| ||
| . |
| ||
| Would need full featured method overloading (as you could do it with any style), which is imho not in. |
| ||
| Well. For big OOP projects I use factories, so it's really not necessary. Actually constructor arguments can be a pain, since they can't really return an error and throwing exceptions inside them can be messy as you have no real control over when they are called :) |
| ||
| the use of factorys is the best solution, better than constructos with arguments. It makes code much more clear (IMHO). anyway, It's allwais better to let the programer choose if he or she wants to use constructors with arguments or not, and in current BlitzMax you can't choose... |
| ||
| Constructor arguments are a nice way to enforce existence of dependencies when an object is instantiated. The gain is, it forces the programmer to provide the class with a base of initialization parameters before the class instance can even exist. Obviously you can work around with factory style instantiation, provided the visibility and scope of the "intializing" properties are not important. It's a "nice to have" that probably has more value to third party component developers than anyone else. |
| ||
| The gain is, it forces the programmer to provide the class with a base of initialization parameters before the class instance can even exist. The same can be said for factory style creation. When you invoke a static create method, you are supplying parameters before the concrete object exsists.What BlitzMAX really needs is private/protected constructors, so that objects cannot be created outside the type in question. |
| ||
| One advantage is perhaps that new could remember the arguments to create obj when going: Local Something:Object = New obj I could see many uses for that, but it would be very dangerous if the programmer wasn't expecting that behaviour, so who knows. |
| ||
| The only problem is that Casting already uses the same syntax as providing a constructor arguement. Widget(obj) Converts obj to a Widget (if it can). However, in order to have constructor arguements, we would also need method overloading (not happening). I'd love to see method overloading and constructor arguments in Bmax. The advantage constructor arguments has over the factory style creation, is that when you extend your class (inheritance), that same old static function only returns an object of the base type, and can't be overloaded. (As far as I know anyway). A way to get around this would be to have your static function return an object, but then you would have to cast the object to your new type whenever you wanted to use it. I'm ALL FOR private, and public access modifiers though. There are some members that you don't want to expose to the public. ;) |
| ||
| The advantage constructor arguments has over the factory style creation, is that when you extend your class (inheritance), that same old static function only returns an object of the base type The disadvantage is that since objects cannot be relied upon to have a 'default' (parameterless) constructor (which would defeat the purpose), you would have to remember to explicitly invoke the super constructor with all applicable arguements, every time. I don't see this as being terribly more convenient that having to write a new factory method. |
| ||
| Explain the significant difference between that and factory style creation. It makes real world coding possible. |
| ||
| The disadvantage is that since objects cannot be relied upon to have a 'default' (parameterless) constructor (which would defeat the purpose), you would have to remember to explicitly invoke the super constructor with all applicable arguements, every time. I don't see this as being terribly more convenient that having to write a new factory method. Then you have sloppy code with dead limbs hanging off of it. Because the old Factory function is included in the new object along with the new one. *Code Bloat*. There's nothing wrong with writting a simple line of code to call the base constructor. C#/Java programmers do it all the time. |
| ||
| Because the old Factory function is included in the new object along with the new one. *Code Bloat*. What do you mean by included, and how does it make bloated code? It makes real world coding possible. Real world programmers disagree with you. There's nothing wrong with writting a simple line of code to call the base constructor. I didn't say there was something wrong with it. I asked how it was significally different. C#/Java programmers do it all the time. That's a rather poor argument considering we're not discussing the merits of C# and/or Java. There are litterally hundreds of things C# and Java programmers do 'all the time' (like runtime reflection and generics) that for one reason or another doesn't apply to Blitz.If you wanr to make an arguement thst BRL should spend time implementing the functionality you want, you're gonna have to do better than real world coding and Java/C# copycats. |
| ||
| From a syntactical stand point proper "constructors" makes more sense then using a Function, but its nothing more than syntactical sugar, since the underlying implementation will be very similar. Still id like to havem to ;) |
| ||
whats wrong with a create method that calls new and returns a local instance?
Type MyType
field name:String
Method MakeCreateWhatEver(str:String)
Print "New "+str+" coming right at ya!"
local t:MyType=new MyType
t.name=str
End Method
End Type
Global tt:MyType = MyType.MakeCreateWhatEver("Ontario")
print tt.name
or am I missing somthing obvious... |
| ||
Chris: Which is longer? Which is easier to type? Which is made of real cheese and which is made of that fake, bad-tasting American cheese (no, I don't mean in the national sense, I mean the type of cheese that Kraft sells)?
Global tt:MyType = MyType.Create("Ontario")
Global tt:MyType = New MyType("Ontario")
|
| ||
| What do you mean by included, and how does it make bloated code? When you extend the type into a new type the Factory function (Create, whatever) is also present in the new type. Then, it only returns an object of the previous type, and since it can't be overridden, you have to create a new Factory function with a different name. Even though you will never use the old 'Create' function again, it is still there. Code Bloat Real world programmers disagree with you. Is that the best you can do? I'm a real world programmer, and I fully agree with what he was saying. In the real world we use languages such as Java and C# to create enterprise wide applications. We have an intricate knowledge of these languages. We know the benefits of features such as method/contructor overloading, and public and private access modifiers. If you wanr to make an arguement thst BRL should spend time implementing the functionality you want, you're gonna have to do better than real world coding and Java/C# copycats. How about promoting clean coding habbits? Do you even know anything about Java or C#? I'm not bashing BMax. It's great... So far... What I would REEELY like to see the most is Public and Private Field/Method access modifiers, and Method Overloading. -Jim |
| ||
| When you extend the type into a new type the Factory function (Create, whatever) is also present in the new type. Then, it only returns an object of the previous type, and since it can't be overridden, you have to create a new Factory function with a different name. Even though you will never use the old 'Create' function again, it is still there. Code Bloat If I have a function that relies on factories and needs arguments specific to a specific factory, then I put the arguments in a bank and pass them. That way the factory in specific gets its information from the Url by casting to a TBank and checking to see if it's not Null, and all the other factories ignore it unless it's the correct input. Just my 2 cents. |
| ||
| Good advice. Thanks. I've been having the Create function return an object, and then I would just cast the object into whatever the extended class would be. Still a pain in the keaster to remember to have to cast your new objects though. |
| ||
| I have a base class with an abstracted public interface. If an extended class ever needs more than that, then I've done something wrong. Then again, a base class never needs anything more when I can just implement SendMessage. |
| ||
| Me likey! Pretty much like what I've been doing, but for 'impromptu' programs I often just use 'object' as the base class. |
| ||
| Then, it only returns an object of the previous type, and since it can't be overridden, Yes it can, providing you use the same number and types of parameters. Worked like a charm so far. Guess that's the advantage of up-front design, over code and fix. Is that the best you can do? Nope. It was directed at Warren. Didn't want to go all polysyllabic on the poor thing. We know the benefits of features such as method/contructor overloading, and public and private access modifiers. As does Mark and Simon, and pretty much everyone else tsaking part in this discussion. Appearently we don't all share you and Warrans view. I guess there really isn't only one ring to rule them all. How about promoting clean coding habbits? Do you even know anything about Java or C#? Since you asked, yes. I've been programming in Java since about version 1.2 (6 or 7 years, I lose count) and C# for about a year and a half. Why do you ask?Incidently, are you seriously suggesting that 'promoting clean coding habits' is the major focus in a language that has Goto? Ich don't think so. |
| ||
| On the last sentence: that would end bad ... you know that C# has goto, don't you? ;-) |
| ||
| Well no. I didn't actually. For real? Wow. |
| ||
| Real world programmers disagree with you. And how many of those do you know? Thanks, drive through. |
| ||
| And how many of those do you know? More than you can count. |
| ||
| More than you can count. That's not a lot. |
| ||
| Have you guys considered using logic instead of childish bickering and the repeated use of fallacies and rhetoric? If you can't find the irony in that statement, you're beyond my help. |
| ||
| More than you can count. Fellow students don't count. |
   |