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.
* 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.