Mark, Possible Features?
BlitzMax Forums/BlitzMax Programming/Mark, Possible Features?
| ||
| Mark and crew, I have a list of features/changes to bmax that I think would be very good. Mark/Skid/BRL - Please, just tell Yex/No for each of these, and if no, why? Others - If you have something to add, post your suggestion, and keep the numeric order so that mark/skid/brl can answer all of the suggestions since their last answer efficiently. If someone thinks they have a really good counterargument for a reason not to have a feature, post it. 1. Private elements types, it's ok if the private is file to file basis, prefereble if its private to the type. 2. Overloading Functions/Methods 3. C#/Java style properties 4. Change "Abstract" to "Template"? 5. Ability to create an "Addition" flag on type decleration that adds/replaces the elements to the type that is the same as this "addition" type. Might be hard to implement with modules, but that would be the prime usefulness. This would be an insanely convenient way to modify the modules without actually modifying them. It would be harder with non-oop modules, but internally most modules are oop anyway Things I know other people will want: 6. C++ Style templates 7. Overloading operators - imho overused, should only be used for mathematical or set objects. It would be nice to have, but worth the time implementing it? 8. Namespaces 9. SetBuffer()? 10. 1 or 2 charachter bloxk commenting |
| ||
And an alias to Rem/End Rem please!/' this text is rem'd! Just like Rem/End Rem '/ ------------------------------------------------ EDIT: Woops, sorry. Didn't read all the suggestions too well. It's already in Botbuilder's list. |
| ||
| 1. Overloaded Functions This would be very useful, other than that I am happy with the OO implementation as it is now. |
| ||
| #1 Private access modifiers for globals, consts, functions, and methods within a type. I was surprised by how much I miss this. #2 Overloaded functions and methods can be useful. #9 SetBuffer() #11 Assignment operators (+=, -=, *=, /=, %=, <<=, >>=, &=, ^=, |=) #12 Vectors and matrices as built-in types. Then we wouldn't need operator overloading. Many games use vectors, so built-in support for them would make code much simpler. The rest I'm not fussed on. |
| ||
| Wayward, for #11 you can do this, only like this: i:+1, i:*2 etc. Also, for #12, add Quaternions. Mark, I know you know how to implement these, but check out http://gamemath.com/downloads.htm the code from this book for some rather well-thought out classes. |
| ||
| Bot Builder: Don't see the use of 4. Abstract and Template are 2 totally different things and a rename of that would lead to a lot of problems with C programmers that don't understand the world anymore. |
| ||
| 1. GUI MODULE 2. Everything else... |
| ||
| Agree with: 1, 2, 3, 5, 6, 7, 8, 10, 11, and 12. Amazing just how much you'll come to miss the lack of private members. |
| ||
| a cross platform GUI module would be a great benefit, as it's kind of a pain to make a true cross platform app without one. Most people would probably neglect the mac otherwise, and the mac community may then lose out on some cool tools. so I agree with Rich05 |
| ||
| Dreamora - the argument has occured.. http://www.blitzbasic.com/Community/posts.php?topic=42819 My general argument is that bmax shouldn't particularly cater to C++ programmers (Not C, actually) Good points on GUI mod, but these are more general language suggestions though. Maybe make another thread for module suggestions? Mark, you can say "Maybe" for a few of them, If you would like to implement them but it might be too hard/take time away from making modules in high demand (3D/GUI). Also, Dreamora, these language features should be implemented before since they will make writing gui/3d mods much better/elegant. Particulary Private/Properties for the GUI, as you can for instance, set the field "width" of a control and the property will call the apropriate internal commands. |
| ||
| And see with BMX, the great thing about a gui module is that you could easily edit it to change the current gadgets or make your own ones. So a gui mod would be a very good addition to this great language. |
| ||
| I'm sure there is at least 1 GUI module in the works as we speak (the B+ module), so I'm just waiting patiently... But I'd really like to see someone with a lot more gray matter than me come up with as near perfect a solution for this as possible. Some suggestions: 1) The BMax commands for creating GUI elements and receiving events, etc. should be the same on all supported platforms. Cross-platform portability is the main reason a lot of us bought Bmax, so catering to Windows only or Mac only will only split us apart! 2) The windows and other GUI elements themselves should be 'proper' native OS GUI elements, rather than Max-created elements. Some people may not agree with this (and maybe they have good reasons), but I think BMax will get a lot more respect if it does it this way. Plus, it will almost certainly be easier since most of the hard work has already been done by Microsoft, Apple or whoever! 3) Supporting OS-specific events, gadgets (sorry, that's what I call 'em), etc should also be possible, of course, through some clever means. Any ideas? Naturally, the features that ALL of the supported OSes share should be the common base. I could be wrong, but I'd guess that 90% or more of these features are shared already by these OSes. Afterall, are they not all event-driven pre-emptive multitasking operating systems that use graphical elements such as buttons, windows (Microsoft calls EVERYTHING in the gui a 'window' practically), menus, etc to interact with the user? 4) Along with the GUI module, I'd really like to see, of course, a Visual Designer (oops, I think that's PureBasic's area) or whatever GUI editor to top things off. So far, I'm just having fun experimenting with BMax's 2D capabilites. But application programming is also on my mind, and BMax seems open enough to handle it with 'gusto' <crosses fingers>. Russell |
| ||
| I am tinkering with a win32 only gui module aswell. The only thing I can think of, which I am sure you all agree with, is to get rid of the framework nonsense and make the compiler detect which modules are being used. |
| ||
| The compiler could detect what modules can't possibly be used, but we'd still need framework to tweak it by hand. |
| ||
| skn3 - I agree 13. Autodetect modules used (release mode only?) could take a bit more time to do the extra processing. This will be one of the core features of my preprocessor, but its better implemented in the compiler. Maybe an ultra-release mode that even strips down all unused stuff from the modules used, placing these stripped down versions in the tmp directory for a very long compile. This is a possible feature of my preproc. Russel: this has been discussed before. 1) Of course. This is best achieved by first creating an abstract class for each control, each inheriting from "gadget" or "control". Then, in each platform specific file, the abstract classes are implemented and 2) Yep 3) See 1. For GUI, personnaly, I'd prefer two methods, one my own and one from this python native gui thing. My own is that in the abstract classes there are fields (properties, actually - MARK - GUI MODULE WILL NEED THESE TO BE ELEGANT), that give info on sizing of conrols, dimensions, etc. This will allow you to position cross platform, but it requires quite a bit of coding on the user side. Other positioning methods can be built upon this. For instance, the python thing's gui system was to define a window like an html table, and place a control in each data area. Not html ofcourse but it was like html. It was reasonably easy. The editer for my method could be where you say, define all components as attaching to other components, with a certain pixel distance between them. this sounds limiting, but it is for the most part how the VS2005 gui editer works for the most part and it is VERY convenient because all your stuff is lined up and neat. 4) see 3 Anyway, it'd be nice to carry the gui discussion to another thread. This wasn't created for discussing a gui module, it was created forr getting a response from BRL, which seems impossible. |
| ||
Multiple inheritance of interfaces or abstract classes.
Interface Readable
Method Read()
EndInterface
Interface Writeable
Method Write()
EndInterface
Type test Implements Readable,Writeable
Method Read()
Print "Readable"
EndMethod
Method Write()
Print "Writeable"
EndMethod
EndType
Function ReadTest(a:Readable)
..
Function WriteTest(a:Writeable)
..
|
| ||
| Hi, * Abstract -> Template: I can see no good reason for this beyond some people may prefer it. Myself and some others wont. Besides, doesn't 'Abstract' have that cool, 'sci-fi' feel? * Private members: These will likely happen once the language is 100% stable and settled in a bit. The reason this was left out was to keep things simple. Once you get into 'private', you start thinking about things like 'friend/package' and 'protected'. However, I now consider 'Include' to be the solution to 'friend/package', and 'protected' to be bad practice anyway! * Overloaded functions: These are tricky. The idea is nice, but there are several 'gotchas'. For example... Function T( x:Float ) End Function Function T( x:Double ) End Function T 10 'what gets called? Float, 'coz it's 'closer' to Int? Double 'coz it's more precise? Error because there's no exact match? ...or... Type T Method M( x:Float ) Method M( x:Double ) End Type Type D Extends T Method M( x:String ) End Method Method Q( x:Int ) M x 'what happens? End Method Method Q( x:Float ) M x 'And this? etc... End Method End Type Yes, you can come up with rules for these situations, but in my experience there is no avoiding 'surprises' with overloaded functions whatever rules you pick. Blitz's 'relaxed' attitude to type conversions also complicates things. * Properties: I have never used these myself by I must admit to not being 100% happy with the idea of simple assignments or variable usage doing 'magical' things behind my back. I like to think that: x.y=10 ...will always take constant time to execute and have no 'side effects'. With properties, this is no longer true. The situation is vaguely similar to classic basic style arrays, eg: a=x(10) 'how fast will this be? Is x() a func or an array? ...vs... a=x[10] 'this *will* be fast! ...all of which is not to say that overloaded functions or properties will never happen, just that I have reservations about them. * GUI module: We are working on a gui module, but there is absolutely no release date or hard info available as yet. The big issue with a GUI module (which relates to the infamous lack of 'GetKey') is a nice event handling system. There are many solutions to this, like Win32/BlitzPlus's global message queue (not so nice), TrollTech's 'slots and signals' (nicer) and ObjectiveC's dynamic messaging (nice) but we haven't decided on anything concrete yet. * Getting rid of Framework: There will always be a need for something like Framework. Consider: p=LoadPixmap( "mypixmap.png" ) A super smart compiler (although none I know of) could theoretically figure out to only link with the PNGLoader module, but... p=LoadPixmap( Input$() ) ...would really be forced to conservately link with all pixmap loaders, which wont always be what you want. |
| ||
| * Getting rid of Framework: There will always be a need for something like Framework. Consider: p=LoadPixmap( "mypixmap.png" ) A super smart compiler (although none I know of) could theoretically figure out to only link with the PNGLoader module, but... p=LoadPixmap( Input$() ) ...would really be forced to conservately link with all pixmap loaders, which wont always be what you want. There is a solution then. When you compile it should figure out which base mods are being used. Then it should list the possible child modules that base module could be using. ... [x] - brl.streams |_ [x] brl.sockets |_ [ ] brl.ramstream [x] - brl.Pixmap |_ [ ] brl.pngloader |_ [x] brl.bmploader |_ [ ] brl.jpgloader ...The user can then choose which should be allowed to compile into the program. This way you can compile a program and it will strip out what is not used, and ask for prompt when the case arises that the compiler can't know. |
| ||
| T 10 'what gets called? Float, 'coz it's 'closer' to Int? Double 'coz it's more precise? Error because there's no exact match? /\. It's better than the alternative(None.) although casting to the nearest base type is better than none too. |
| ||
| I'm not sure why framework is such a problem. If you can't figure it out, don't worry about it until you actually want to release the program. It's not like you should be tinkering with it before every compile, and I don't really like the thought of added compile time or an extra interface like skn3 suggested. An interface like that could be a side option for configuring frameworks and imports though. However, ideally while developing, I should just be able to hit compile and go. I'd rather optimise at the end. I'd say some of the basic language issues like GetKey should really be fixed before we worry too much about the OO stuff. That said, I wouldn't mind any of that stuff being added. The more BlitzMax becomes like the stuff I do at work, the easier it'll be for me to switch at home. As long as these things can remain mostly optional for those not ready to jump into OO. |
| ||
| It's better than the alternative(None.) This would remove implicit casting on function calling totally, making BlitzMax a lot less beginner friendly. |
| ||
| Beginners aren't likely to be overloading methods anyway. And anyone overloading a method with both float and double needs to be slapped. :) I think if Blitz can't determine precisely which function to call, then spit out an error. C++ does that and nobody has a problem with it ... if it's ambiguous, it's up to the programmer to slap a cast on the argument to make it clear. Properties - I agree they are kind of advanced and it sucks when it isn't obvious what code is doing when you read "a = 10". I don't think these have any place in a basic dialect. |
| ||
| This would remove implicit casting on function calling totally, making BlitzMax a lot less beginner friendly. An acceptable side-effect to me(I'd prefer enforced C++ style casting anyway..) Maybe not for mark, but then the alternative is to keep casting where possible. Everyone wins then. nd anyone overloading a method with both float and double needs to be slapped Classes(or types............) are another matter though. Object doesn't fill the void. which is also missing. |
| ||
| First off thanks for getting back to us on our requests Mark, I appreciate hearing your thoughts. - Properties I agree that there is no need for properties in Blitz. If you want properties then write accessor methods( getXXX / setXXX) and access your member variables through them. I have seen mention that Java supports Properties... there is a Properties class, but that is not the same thing. Java allows you to make private member variables and access them through set and get functions. - Overloading A simple solution to the overloading problems is to come up with rules as to which variable types automatically convert and which need explicit casting. In Java these rules are defined by if data is lost in the conversion, ex. float is not automatically converted to int, because data is lost, but an int will be automatically converted to a float, no problem because floats hold more data than ints. So if data is lost in conversion, don't allow automatic casting and require them to explicitly cast. If a user wants to assign a float to an int then require them to cast. Here is Java's scheme for automatic conversion (as best I can remember): char->byte->short->int->long->float->double By determining rules for automatic casting between types then overloading functions would make Blitz Max an even more powerful language. As for your example, in my opinion, both would call M(x:Float), int automatically casts to a float, the closest larger type... I agree with WarrenM, writing a function one taking a float and another a double is asking for problems, but by defining rules for automatic casting these problem would be solved. |
| ||
| Thanks for the response mark. -Properties you bring up some good points on that. I still think they are applicable for updating a Type which uses fields. With current methods if you want to insure being able to add code to field setters/getters you have to make get/set methods from the start and make all fields private. Not only ugly, this clutters up your type quite alot. With Properties, you can simply make your class with fields and if at some point, you decide to add code to setting/retrieving a variable, you can without breaking back-compatability. Bit of a silly example: Type TGadget Abstract Field X,Y, Width, Height Field Caption$ End TypeLets say that originally you would just set values and an "UpdateGUI" function would be called. Later, you decide a more imediate method is better: -Overloaded methods Well, yes, type casting might be a bit tricky, but stuff sugested where the compiler looks "up" the data types would work. I think its not a bad price to pay. Also, yeah, I doubt noobs will use it much. Most of my features - properties, overloaded members, and private members are target at diffucultys and solutions in writing modules. I'd say that a decent variable casting scheme could be created that worked in most cases. -Getting rid of Framework Hmm. You are correct, mark only an uber compiler could figure that out. Maybe an interpreter XD... It would be possible to code for special cases but this isnt really the greatest idea. Perhaps in release mode, though, only include the necessry modules, no matter if it can't figure out exactly which in that specific case. |
| ||
| I would like to put in a request for having Public, Private and Protected Methods and Fields in types. When designing classes, these modifiers help a tremendous amount. I'm not sure why you don't like Protected, but I think it's key to good Class design. Right now, All methods are visible to any derived class and to anything working with an instance of the class. There are certain things that I need to keep hidden from both of those. There are also things that I want to implement in the class, and possibly override in a derived class, but should not be accessible outside the class/derived class. Public is more of the "Outside World" interface to the class. Protected is for things that you are implementing in a class, but you can see that it might be a good idea to override it in a derived class. Private is for things that only really apply to the class they are implemented in. They will never be overriden. This would be extremely useful for creating a Class Library that others could use. If you have 20 methods, how do you know which ones you should really use and which ones are meant for the class itself to use? Here is an example of how I might use it (very simple example, might not be as real-world as it could be, but it should still show my point) Type TMyBaseClass Protected Method UpdateAnimation() ' We do something here... End Method Public Method Draw() UpdateAnimation() End Method End Type Type TMyDreivedClass Extends TMyBaseClass Protected Overrides Method UpdateAnimation() ' Now we do something different here... End Method End Type ' The only method we can call is Draw() x = New TMyDerivedClass x.Draw() ' This is Ok... x.UpdateAnimation() ' Would not work as it would be proteced. Now I'm not saying I can't work around it, however, it's just different enough from the majority of OOP implementations that it will drive me a little crazy :-) |
| ||
| Everybody seems to want C++ features, and BlitzMax would get more difficult and difficult, why dont you guys just move to C++ and buy nice engine for it (or even use a free one)? Some of these features are ok but you need to draw the line somewhere. This is basic after all... |
| ||
| Who said anything about C++ features? I'm talking about OOP features here. BTW: This isn't BASIC. It's a Hybrid of BASIC and what ever else Mark wanted to use. Why do people have such a problem with people asking for features that would HELP one person, yet not force another person to use them? Just because PRIVATE, PUBLIC and PROTECTED were available wouldn't mean you would have to use them. I also don't get the "This is going to make BMax so complictated to use!" when the majority of these features are optional. If you don't understand the feature, don't use it. Those of use who DO understand it, can take advantage of it. The reason I chose Blitz is because it is the best tool for the job. It doesn't mean that it's perfect and that it can't get better. I could easily write a game in C++ or Delphi or what ever, however, I don't want to because it would take 10 times longer. |
| ||
| This is basic after all... Nawi, I agree with your point but I don't think we're in basic country any more. |
| ||
| If you've got classes might as well have protected/private/properties.... |
| ||
| Everybody seems to want C++ features, and BlitzMax would get more difficult and difficult 1. These aren't C++ features, these are common object-oriented language features. 2. BlitzMax would only get more difficult if you chose to use the features without knowing what they did. The common presumption would be that all constructs would be Public by default, and thus work regularly if you didn't take advantage of the features.. 3. BlitzMax has moved a good ways from being a standard BASIC language. |
| ||
| T 10 'what gets called? Float, 'coz it's 'closer' to Int? Double 'coz it's more precise? Error because there's no exact match? I personally would rather that the compiler complained in such circumstances because there is an ambiguity, so the programmer will have to explicitly cast the argument to Float or Double. What is most important though, is that whatever the behaviour of overloaded functions, it is well documentated and consistant. Edit: I agree with Mark about properties - they can be quite misleading, and as I see it, there is no harm in just having accessor functions instead: Where: setField() field() Changes the internal field _field. |
| ||
| What I don't get, is that stuff about function overloading. Is this about writing 2 functions with the same name and let Blitz decide which one gets called? Why would anyone do that? I don't see the benefit of it. I read something about automatic casting, so Blitz could decide, based on a couple of rules, which one to call. But when you have 5 functions, all with the same name and there is a bug (it doesn't throw an error, but does something different than you want), how do you go about debugging that? Then you would manually have to follow these rules and understand the inner workings of BMax, just to find the function where the bug is located. AFAIK, OpenGL doesn't do this. When creating a new vertex, you would call glVertex2i, glVertex2f, glVertex3f, glVertex4d, ... Instead of calling glVertex, and let OpenGL decide what to do with the parameters. Is it really so wrong to have different functions which do the same, but with different parameters types? For me, this would only increase the confusion when debugging. But I do support the addition of private fields. These fields should only be modified by the methods in a type, and not by external functions. If the user should be able to set and read those fields, just create Set and Get methods. |
| ||
| But when you have 5 functions, all with the same name and there is a bug (it doesn't throw an error, but does something different than you want), how do you go about debugging that? Generally speaking there is one "master" function, which actually does the work, and has many parameters. The other functions convert data from one format into the form required by the "master" function, and then call it. The trouble with OpenGL's approach is that it becomes very irritating when there are many variations of the same function, since you have to remember both the function name and the parameters accepted. With the aforementioned OpenGL functions it is usually quite easy to come up with an intuitive name for the different functions (glVertex2i vs. glVertex2f). But what about more complex differences? Rect newRect=Rect.createFromCoordinates(x,y,x2,y2) Rect newRect=Rect.createFromCoordinateAndSize(x,y,size) Rect newRect=Rect.createFromPoints(pointA,pointB) Rect newRect=Rect.createFromPointAndSize(pointA,size) vs: Rect newRect=Rect.create(x,y,x2,y2) Rect newRect=Rect.create(x,y,sizeA) Rect newRect=Rect.create(pointA,pointB) Rect newRect=Rect.create(pointA,sizeA) In the end, it does boil down to a convenience issue, but I think it would make a lot of sense in 'Max. |
| ||
| @PowerPC630: Ther is alot of use for function overloding:) maby you want more than one Create "construktor" with different parmameters, so what shod you call the other? makes alot more sence to use the same name, and let the compiler shose by the nummer of parmameters. this happend in my latest particle projekt, was a problem with extended partikels from a main partikle, now, i cant have a construktor in the sub class named the same as the main construktor with different parmameters doing different stuff, so i have to create a new construktor in the sub class to do some different stuff in each. this was very big pain in the ass. like: type TBase function Create:TBase() end function end type type TSub extends TBase function Create:TSub(TFoo bar) ? end function end type now, the construktor Create() here, is from the TBase type, so if i want to do somting else in my construktor, o have to kall it somting else than Create() wen i create a sub objekt. in my projekt, i had to call alla the construktors stuff like Create_missile() and so on, cus i codent overlod the Create() and i had to do different stuff in all the construktors.... of corse, i can use the base "construktor" named Create, but that may not be what i need.... and for the rest of the stuff here, i agrie with Mark, i have never liked Propertys, i dont like that "magical-somthing happens behind my back" fealing eather, and it seems very strange to me that one can set an variabel and that it also do a mystical function call(for example) in the back... wen i looked att some stuff in delphi using this, it was very hard to know exaktly what the hell was going on ther, one never knows if it is a variabel set, or somting else... so very confusing.... other than that, most of the stuff here is right, i dont mind the abstract stuff doh. a whodent mind shange the name global to static, but i gues mark has alredy made up his mind, and we are not going to shange it eather. but i do want to se som private/public stuff in types, i realy miss that, and i dont think it komplicates stuff if types fields are public by defult, if one dont like private, dont use it... i fail to se the problem here. on the type overloding problem, i want an compiler error here, no magical solutions on convertions and so on. well, thats it fokes =) |
   |