NewsForumsCodeLogsGallerySpecsSearch

New features for Bmax needed

BlitzMax Forums/BlitzMax Programming/New features for Bmax needed

sebas76(Posted 2009) [#1]
Hi to all bmax coders,

I'm an experienced coder from years : I've coded in C/C++/ASM.
I code also in bmax for a CAD software but I'd like to know if the following features will be integrate in bmax soon :
- redefinition of operators like +, = , * , / because it is very useful for vectors and matrix operations.
- multiple definition of the same method in Type like :
Type
field ...
Method set( c:color )
Method set( r:int,v:int,b:int)
...
End type
- a full documentation with all features like reflection etc...

Thanks.


therevills(Posted 2009) [#2]
Hi Coconut

I hate operator overloading! It makes code very unreadable... I know its got a place in coding but meh! LOL

I dont think it will every get added to BMax.

Method/Function overloading would be great, but again I dont think it would get added to BMax.

Regarding documentation, I find that you can find most of what you are after from these forums :)


sebas76(Posted 2009) [#3]
Hi therevills,

I like operator overloading : why ? simply because I use a lot of graphics functions with vectore,points,matrix...
and it is simple to read :

v1,v2,v3:vector
v1=v2+v3

or

v1 = v3.add(v2) ?

Doc through forums is not a good way, I prefer a real manual with all functions / type describe because sometimes you need to search a little more with forums.


Brucey(Posted 2009) [#4]
Doc through forums is not a good way, I prefer a real manual

I have to agree.

And method overloading would make wrapping 3rd-party c++ libraries much simpler for those that do it :-p


_JIM(Posted 2009) [#5]
Method overloading is probably the feature that I miss the most in BMax.


Winni(Posted 2009) [#6]
When you listen to James Gosling and the other Java "fathers", operator overloading is evil. That's probably why they used themselves only for the string class...

I'd rather like to see a 64-Bit port of BlitzMax (my bet is that OS X 10.7 will be 64-Bit only) and good and exhaustive written documentation. I'd also like to see Brucey on BRL's payroll and his modules become part of the official BlitzMax package(s) (bah.mod -> BlitzMax; qtMax/wxMax -> MaxGUI).


Czar Flavius(Posted 2009) [#7]
Can't someone just make a sophisticated preprocessor that adds all these niceties to Blitz? If the IDE can interpret them appropriately, you'd never know the difference!

For example

Type vector2
	Field x:Float, y:Float
	
	Function Create:vector2(x:Float, y:Float)
		Local vec:vector2 = New vector2
		vec.x = x
		vec.y = y
		Return vec
	End Function
	
	Method +:vector2(v:vector2)
		Return vector2.Create(x + v.x, y + v.y)
	End Method
End Type

Local a:vector2 = vector2.Create(5, 10)
Local b:vector2 = vector2.Create(2, 4)
Local c:vector2 = a + b
Print c.x + ", " + c.y


is simply converted by the preprocessor behind-the-scenes to the following Blitz code:

Type vector2
	Field x:Float, y:Float
	
	Function Create:vector2(x:Float, y:Float)
		Local vec:vector2 = New vector2
		vec.x = x
		vec.y = y
		Return vec
	End Function
	
	Method plus:vector2(v:vector2)
		Return vector2.Create(x + v.x, y + v.y)
	End Method
End Type

Local a:vector2 = vector2.Create(5, 10)
Local b:vector2 = vector2.Create(2, 4)
Local c:vector2 = a.plus(b)
Print c.x + ", " + c.y


Of course there is the problem that the user might also define their own method called plus as well as overloading the + operator, but oh well it's an acceptable cost. Perhaps the generated names by the preprocessor could be prefixed with some special sequence of characters that are not likely to be used as a real name by a human. It's never seen by the user, so doesn't have to be readable.

The preprocessor could also add all kinds of other wonderous things to the language, such as function overloading, enumerations, inline functions, the list goes on!


TaskMaster(Posted 2009) [#8]
The only problem that would cause is that the debugging information would not correspond to your code exactly. And the farther into your program the error, the farther off the debugging info will be.

For instance, if your pre-processor adds a line everyone once in a while, it may have added 8 lines before the error in your code. Then when the debugger say there is an error at line 88, it is actually line 80 in your code, unless you look atthe code that came out of the preprocessor...


EOF(Posted 2009) [#9]
Method/Function overloading would be great
+1 vote from me. It means I could then write a function to handle muliple variable types:
Function contract:String[](arr:String[],numElems:Int)
	Return arr[..numElems]
End Function

Function contract:Int[](arr:Int[],numElems:Int)
	Return arr[..numElems]
End Function


Maybe there is a technical reason why this cannot be implemented in BlitzMax though


Czar Flavius(Posted 2009) [#10]
The only problem that would cause is that the debugging information would not correspond to your code exactly.
I have thought about that. The only solution I can think of is that there is some kind of mapping between "old" line numbers and "new" ones by the IDE. Lines unique to the preprocessor could be invisibly marked, and skipped for debug highlighting purposes.

Or by careful use of the semi-colon, additional generated lines can be squeezed upon the same line of code. It doesn't have to look pretty.


GaryV(Posted 2009) [#11]
Doc through forums is not a good way, I prefer a real manual with all functions / type describe
Please let us know when you get it finished.


Gabriel(Posted 2009) [#12]
I must admit that the more I play with "real" languages like C#, the more I miss operator overloading (yes, it's evil if you abuse it, but so is everything if you abuse it) method/function overloading, properties, interfaces, inline functions, inline structs, and ACCESS MODIFIERS THAT ACTUALLY HAVE A USE (weep) when I come back to program in BlitzMax.

Sadly, I don't expect to ever get them. Mark tends not to do major overhauls like that. He's more likely to just relent one day and give us one or two of those features as he did with threading, but I can't see BlitzMax ever getting that kind of full overhaul. Shame though, as I might let C# lead me into temptation.


Czar Flavius(Posted 2009) [#13]
The power is in our hands. I'm going to make a preprocessor called SuperBlitz to add all these features, and hopefully can figure out how to make a plugin for Blide to make it not suck for actual use. The first thing I will add is operator overloading as that seems the easiest. Does anyone have a list of characters that are acceptable in function names? All I need is a weird character that nobody would ever use that can be in a function name and away I go.


Brucey(Posted 2009) [#14]
the more I play with "real" languages

Pah...


_Skully(Posted 2009) [#15]
the more I play with "real" languages

Oh damn... and I used real money to buy this fake language!

Double Pah!


Arowx(Posted 2009) [#16]
Wow philisophical what is real and what is not...

I like Terry Prachett's view everyones reality is their own, think of everyone walking around with their own little universe floating around their heads and you get the picutre! ;o)

Arguably a good intellisense parser in the IDE that would interprit '+/-*' depending on context allow you to type shorter code but provide full debug code...?!

What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" : Terry Pratchett



Corum(Posted 2009) [#17]
+ 1 for intellisense feature.
+ 1 for Method/Function overloading.

I used real money to buy this fake language!
This is priceless! ^_^


Kurator(Posted 2009) [#18]
I would give my neighbours right hand to get generics and interfaces into bmax ;)


Htbaa(Posted 2009) [#19]
Method, Function and Operator overloading would make me happy.
Also, I'd like to have interfaces, or multiple inheritance.


Gabriel(Posted 2009) [#20]
I would give my neighbours right hand to get generics

Oooh, I forgot generics. They're nice.


ziggy(Posted 2009) [#21]
Add properties to the list, and please put it a big red lace at the top and leave it under my christmass tree...


N(Posted 2009) [#22]
I would give my neighbours right hand to get generics
I would offer a volcano sacrifice of many small children to get generics.


Zakk(Posted 2009) [#23]
I would also like function/method overloading. I think it can be faked in some cases...
Function DoThis(o:object)
	If type1(o)
		DoThis1( type1(o) )
	ElseIf type2(o)
		DoThis2( type2(o) )
	Endif

... but that doesn't allow for floats and ints, without going to the trouble of making an IntObj Type to hold all your ints, etc..


Gabriel(Posted 2009) [#24]
... but that doesn't allow for floats and ints

Yes, I expect that's why Mark would never consider true overloading in BlitzMax. I think he feels that BlitzMax needs to keep to the traditions of inferred typecasting, which puts a bit pretty big barricade in the road to overloading where you really need a very strongly typed language. While it doesn't help me get what I want, if that is his judgement, I respect that, because that's probably the bulk of his market.


Tommo(Posted 2009) [#25]

I would offer a volcano sacrifice of many small children to get generics.



Hope you can find an active volcano in New Zealand...


N(Posted 2009) [#26]
Hope you can find an active volcano in New Zealand...
I will use yellowstone for this.


JoshK(Posted 2009) [#27]
I think both the OP's suggestions would be very useful. Vector math is a lot easier with operation overloading.

However, you should also be aware that the approach that allocates a result will be pretty slow if you are using it heavily:

Either of these:
v3 = v1.Add(v2)
v3 = v1 + v2

Are much slower than this approach which would store the results in v3:
v1.Add(v2,v3)

Assuming you allocate v3 intelligently and reuse vector objects.

Here's what I ended up doing in a lot of cases:

Type TVec3
Field x,y,z

Method Add:TVec3(v:TVec3,result:TVec3=Null)
if not result result=New TVec3
result.x=x+v.x
result.y=y+v.y
result.z=z+v.z
return result
EndMethod

So you can use the method in both the nice dynamic allocation way, or the faster way where you supply the vector for the results.

But anyways, yeah I would love to have the option to do this:

v3 = v1 + v2


Eternal Crisis(Posted 2009) [#28]
Method overloading would be great


Mahan(Posted 2009) [#29]


However, you should also be aware that the approach that allocates a result will be pretty slow if you are using it heavily:

Either of these:
v3 = v1.Add(v2)
v3 = v1 + v2

Are much slower than this approach which would store the results in v3:
v1.Add(v2,v3)





How you spawn and/or reuse instances is up to the implementation of the class implementing the op-overloading.

Provided your class will be instanced/released pretty heavily you could use an instance-pool.

Example of instance pooling:

Let's say you add two class-functions (static methods) to the class in question called as an example: acquire(<init params>) and release(<reference>) and also add a static list/array to the class called "pool" or something like that.

pseudo code for acquire:

func aqcuire:<Type>(<init params>)
  if there are any object(s) in the pool
    local result:<type> = pool.getAndRemoveFirst()
    result.reinit(init params>)
    return result
  else
    return new <Type>(init params>)
  endif

end func


pseudo code for release:
func release(<reference>) 
  Const MAX_POOL_SIZE = <find by experiment a good value for your app>

  if size of the pool is not more than MAX_POOL_SIZE
    pool.add(<reference>)
  endif

end func


The drawback is that this adds the complexity (when using this type) to manage the artificial "life-time" [acquire() -> release()] of the instances, but it might be worth it for very heavily instanced computational classes like vectors in an 3d-engine etc.

edit: clarification.


Marcus(Posted 2009) [#30]
I actually moved back to C++ because of the lack of method overloading and multiple inheritance. BlitzMax would be pretty much perfect with the inclusion of both of those.


Czar Flavius(Posted 2009) [#31]
Mahan could you give an example of that using Blitz code?


Gabriel(Posted 2009) [#32]
However, you should also be aware that the approach that allocates a result will be pretty slow if you are using it heavily:

Either of these:
v3 = v1.Add(v2)
v3 = v1 + v2

Are much slower than this approach which would store the results in v3:
v1.Add(v2,v3) 


V1:+V2

;)


_Skully(Posted 2009) [#33]
I have two TLists, one called list and another called ActiveList

Type A
  Global ActiveList:TList=New Tlist
  Global List:Tlist=New List

  Field Something:int=0

  Method New()
    List.AddLast(self)
  End Method
  
  Method Activate()
     ActiveList.AddLast(Self)
     List.Remove(Self)
  End Method

  Method Deactivate()
     List.AddLast(Self)
     ActiveList.Remove(Self)
  End Method

  Function Create:A(v:int)
     local t:A
     if List.First()
       t=A(List.First())
       t.something=v
       return v
     else
       t=new A
       t.something=v
       return t
     EndIF
  End Function

End Type


That avoids Constructor/Destructor delays and is particularly important for particle effects in game terms... of course, for Particles I'd have an array instead of a TList just to squeeze every clock cycle out of it.


Mahan(Posted 2009) [#34]
@Marcus:

I actually moved back to C++ because of the lack of method overloading and multiple inheritance. BlitzMax would be pretty much perfect with the inclusion of both of those.



Reading your initial post I see you got experience from several languages. As you no doubt have noticed (almost) all languages bring some cool features to the table, but they also have weak points.

For instance in a C++ vs BMX compo (even though I'm no C++ guru) you'll probably see you get pros in C++ regarding op-overload and templates. But BMX also has some serious pros in the array management and string manipulation area: The manipulation of slices (I guess BRL got some inspiration from Python) is a very elegant and efficient way of handling those.

What I mean is that whenever you write an non-trivial application, and you know a few languages, you'll often get the feeling that: "Hmm, it sucks I'm writing this declaration/method/structure in [language A] right now, because if I'd be using [language B] now I'd write this much more elegant/simple."

There simply is no perfect language for everything, but some languages are better for some specific stuff than others.

@Czar Flavius:

Mahan could you give an example of that using Blitz code?



_Skully's code is probably working, but I don't have BMX installed on this computer to check. If you rewrite it to use static arrays and array-pointers instead (just as _Skully mentions) you'll get optimal speed without significant need for costly alloc()/freemem()- calls in runtime. (presuming you can somehow estimate/test what size the array should be to work well.)

edit: spelling, clarification


JoshK(Posted 2009) [#35]
function Normalize:TVec2(v:TVec2)
function Normalize:TVec3(v:TVec3)
function Normalize:TVec4(v:TVec4)
function Normalize:TVec3(x:Float,y:Float,z:Float)

Type TEntity
Method SetPosition(t:TVec3)
Method SetPosition(x:Float,y:Float,z:Float)
EndType

Not absolutely needed, but if it were one day added, I would be quite happy.


N(Posted 2009) [#36]
For instance in a C++ vs BMX compo (even though I'm no C++ guru) you'll probably see you get pros in C++ regarding op-overload and templates. But BMX also has some serious pros in the array management and string manipulation area: The manipulation of slices (I guess BRL got some inspiration from Python) is a very elegant and efficient way of handling those.
Not to rain on your parade, but I think operator overloading and generics really trump slicing here...


Czar Flavius(Posted 2009) [#37]
of course, for Particles I'd have an array instead of a TList just to squeeze every clock cycle out of it.
You should store the TLink in each particle, because TList.Remove is very slow!


Dabhand(Posted 2009) [#38]
lol, I recall asking for operator and function overloading donkeys ago in one of them 'Whats good/bad about BlitzMax' threads, which, apart from being flamed at the time, it did indeed fall on deaf ears too!

I'd love to see proper constructors and destructors:-

Type TFoo
    Field iVar:int, sString 
    Method TFoo(a:int, b:string)
        iVar = a
        sString = b
    End Method
 
    Method ~TFoo()
        'Called automatically when the garbage collector cleans up
    End Method
End Type


In the same respect, I'd also like to see function templates:-

FFunction <T:Object> Max:T(x:T, y:T>
   If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function

Print Max(1,5)
Print Max(1.2,3.7)


Okay, thats a bit of p-code, and I have no idea how such a thing could be handled in BlitzMax, but, it would be cool if you can do something like that in Max, as theres been a few times I've needed two variations of the same function to handle different data types, and yes, function over loading would get over it in a much elegant way, but this, in my view, is a lot elegant'er too! :)

Dabz


Brucey(Posted 2009) [#39]
I'd love to see proper constructors and destructors ... In the same respect, I'd also like to see function templates

I think you took a wrong turn something... you should have taken the 3rd exit on the left, at C++


Mahan(Posted 2009) [#40]

Not to rain on your parade, but I think operator overloading and generics really trump slicing here...



Yep, I fully agree. But my point was that both languages got features that the other lacks.


Regarding multiple inheritance:

Personally I reject multiple inheritance, and propose interfaces as a much more viable option (at least partially overlapping), to get the extended typing possibility. Multiple inheritance often (imho) leads to problems when you want to introduce another parent somewhere in a nontrivial inheritance tree, with the result that other subtypes become invalid (from the classic "B is a kind of A" way of thinking).

Looking at many modern programming OOP languages (Java, C#, Ruby etc.) it would seem others also agree in this.


sebas76(Posted 2009) [#41]
Thanks to all for your mind and comments but what Mark think about that ?

It is the problem with Bmax : we don't know where we go : which features will be ingrated next time ?

- Overload method / function is really useful and powerful : you can make more reusable code for the main loop in an easy way : you don't have to select the method to call for each type.
- Operator overloading is very very useful for all graphics apps like game,cad etc...

If only this two things could be implemented very quickly :it will be great else I think I will return to C++.. fortunetaly...

I have a big project that becomes very huge and with bmax limitations it is not so fun to update...


Dabhand(Posted 2009) [#42]

I think you took a wrong turn something... you should have taken the 3rd exit on the left, at C++



lol, okay, I have no idea of what part of my post your implying too, so I take it its all of it! :)

Currently, we have this (From the docs):-

Type MyClass
	Field	a,b,c
	Method New()
		Print "Constructor invoked!"
		a=10
	End Method
End Type

Local c:MyClass
c=New MyClass
Print c.a


Which, it seems to me that this is the basis of a C++ style constructor in BlitzMax, which I would let go, but since I cannot figure a way of passing parameters to the object through New (And if someone knows, then that'll be great), it does seem, in regards to what it should be in the Print statement there, a bit naff!

I would then, in this case, would like to see something like this available:-

Type MyClass
	Field	a
	Method New(b:Int)
		Print "Constructor invoked!"
		a=b
	End Method
End Type

Local c:MyClass
c=New MyClass(20)
Print c.a


In regards to destructor's, I do actually think it would be really handy to have access to one, either usable through the reserved keyword Delete, or when an object drops out of scope.. Yes, C++'s destructors is generally used for deallocating memory and general clean ups, but, it would be nice to have that option to maybe drop debug info when the object goes out of scope or gets deleted.

Moving on to my other babble:-

In BlitzMax, we have to do this:-


Function MaxInt:Int(x:Int, y:Int)
 If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function

Function MaxFloat:Float(x:Float, y:Float)
 If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function


To perform the same test across different datatypes, with 14 lines of code... If we use function overloading, we can do this:-

Function Maximum:Int(x:Int, y:Int)
 If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function

Function Maximum:Float(x:Float, y:Float)
 If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function


Still 14 lines of code we have to write to perform the same task, granted, anyone using the code wouldnt know the difference, but still... Its 14 lines non the less!

Now, if we use my bit of p-code:-

Function <T:Object> Max:T(x:T, y:T>
   If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function


We only need to write half the code to achieve the same results...

So all in all, what is actually wrong with everything I've requested, people have requested reflection, and, even though I'll probably never use that, I wouldnt slate it or anyone that uses it just because I dont need it... Its all about options at the end of the day isnt it?

Dabz


JoshK(Posted 2009) [#43]
I am really glad you p code will never come to exist.

All in all, these kind of features are syntaxic sugar. They are nice, but I would not argue they are crucial. My only real complaint about the language itself is I wish there was a faster non-circular GC for mulithreaded apps, or maybe some kind of GC-less fast track option for some objects, even if it made things more difficult to program.


Dabhand(Posted 2009) [#44]

All in all, these kind of features are syntaxic sugar.



Well, I have a sweet tooth! :D


I am really glad you p code will never come to exist.



And yeah, I know it'll never happen, because I have suggested it before! ;) Hehehe

Dabz


Brucey(Posted 2009) [#45]
it would be nice to have that option to maybe drop debug info when the object goes out of scope or gets deleted.

You mean like this?
Method Delete()
    DebugLog "I'm off now... see ya!"
End Method


I've no problems having generics... but this :
Function <T:Object> Max:T(x:T, y:T)

looks terrible. Really. :-p


plash(Posted 2009) [#46]
I've no problems having generics... but this :
looks terrible. Really. :-p
Ugh.. I agree with that.

Why the :Object bit?


Czar Flavius(Posted 2009) [#47]
Calling it Symbol would look nicer, and more Basic-like.
Function Maximum:Symbol(x:Symbol, y:Symbol)
   If x > y Then Return x Else Return y
End Function

Of course this particular example ignores the problem of what happens if you send a non-number to the generic function. Without operator overloading, it wouldn't make any sense to pass Objects for use with '>' :P

As for constructors, isn't the standard way to do something like this?
Type TPerson
   Field name:String
   Field age:Int
   
   Function Create:TPerson(name:String, age:Int)
      'Constructor
      Assert name.Length > 0
      Assert age >= 0
      Local person:TPerson = New TPerson
      person.name = name
      person.age = age
      Return person
   End Function
End Type

Local p:TPerson = TPerson.Create("Bob", 21)



plash(Posted 2009) [#48]
As for constructors, isn't the standard way to do something like this?
It's not really a standard.

Another way to do it is by using Create as a method (which allows you to reinitiate the object later if you wish to), but again, this is not a standard either.

Calling it Symbol would look nicer, and more Basic-like.
That doesn't look any neater to me.

Of course this particular example ignores the problem of what happens if you send a non-number to the generic function. Without operator overloading, it wouldn't make any sense to pass Objects for use with '>'
Yes, some features are inter-twined, but even if we got generics without operator overloading it would be fine to yell at the developer at compile-time (for trying to use operators on objects).


Dabhand(Posted 2009) [#49]

You mean like this?



Yeah, but, as well as...

SuperStrict

Type MyClass
	Field a:Int
	
	Method New()
		a = 10
	End Method
	
	Method Delete()  'Never called when dropped out of scope, or removed with Null/GCCollect
		Print a 
	End Method
End Type

If True 
	Local b:MyClass
	b=New MyClass 'Init a with 10 inside of New method
	b=Null
	GCCollect
End If



looks terrible. Really. :-p



lol, okay, its not the prettiest, but it does show what I mean though.


Why the :Object bit?



Right, maybe <T:Template> would be better suited... As I pre-mentioned ---> "and I have no idea how such a thing could be handled in BlitzMax", its just an idea that I would like to see, thats all. :)

EDIT: Or what Czar Flavius said, but I whole heartly agree, operator overloading will be a great welcome addition too!

Dabz


N(Posted 2009) [#50]
I propose we just make everything into an object - ints, floats, what have you - and then have all classes, objects, etc. be associative arrays.


Brucey(Posted 2009) [#51]
Yeah, but, as well as...

No... you don't understand how the garbage collector works.

The following app will end when the first MyClass instance is GC'd :
SuperStrict

Framework brl.standardio

Type MyClass
	Field a:Int
	
	Method New()
		a = 10
	End Method
	
	Method Delete()
		Print "It's the end of the world, as we know it..."
		End
	End Method
End Type


While True

	Local class:MyClass = New MyClass
	class = Null

	Delay 1

Wend



Dabhand(Posted 2009) [#52]

No... you don't understand how the garbage collector works



Yep, your right in that regard, lol, it is good to be shown though, I never look too far under the hood in regards to it, more often than not, I just let it run itself!

Thanks for the example, nice treat that... Though, it still would be nice if you can do this though:-


Local class:MyClass = New MyClass(20)



Instead of the methods mentioned above, which yes, are a way of getting round it, but, I dont like 'em really! ;)

Cheers Brucey

Dabz


jsp(Posted 2009) [#53]
Though, it still would be nice if you can do this though:-

Local class:MyClass = New MyClass(20)



You could may write:

SuperStrict

Type MyClass
	Field a:Int
	
	Method Init:MyClass(a:Int)
		Self.a = a
		Return Self
	End Method
	
	Method Delete()
		Print "It's the end of the world, as we know it..."
	End Method
End Type

Local class:MyClass = New MyClass.Init(20)
Print class.a



Brucey(Posted 2009) [#54]
Instead of Init(), I tend to use the method Create().

But they all accomplish the same thing :-)


JoshK(Posted 2009) [#55]
You can always do this, but without method overloading it is pretty limited:
Type TThing
	Field a,b

	Method Create:TThing(a,b)
		Self.a=a
		Self.b=b
		Return Self
	EndMethod

EndType

Local thing:TThing=New TThing.Create(5,62)

Print thing.a+", "+thing.b



Zakk(Posted 2009) [#56]
I usually do something like what jsp does.

I still don't see why 

Local instance:MyClass = New MyClass(10)

Type MyClass
	Field a:Int
	'...
	Method New(b:Int)
		a = b
	End Method
End Type


is so much superior to

Local instance:MyClass = MyClass.Create(10)

Type MyClass
	Field a:Int
	'...
	Function Create:MyClass(a:Int)
		Local instance:MyClass = New MyClass
		instance.a = a
		Return a
	End Function
End Type


It's barely any more work.

EDIT: I also use "Create," but that's just a phrasing preference.


ziggy(Posted 2009) [#57]
I still don't see why [...] is so much superior to

Becouse it allows constructors inheritance. The create function will always return a MyClass and never a derived class of MyClass, while the New method always return the current (derived or not) class, so constructors there would be much more sexy... anyway, we can have a 'several' functions aproach or a method that returns the derived class and expects the calling code to upcast it when needed... not much elegant but it does the job.


byo(Posted 2009) [#58]
+1 Method overloading.

This would really make our Types look shiny! :D


Czar Flavius(Posted 2009) [#59]
+1 Method overloading.
This gives me a compiler error. You surely must mean Method_overloading.Add(1)
;)


_Skully(Posted 2009) [#60]
I still don't see why


Because someone can always go around your code by using New by itself, which totally bypasses your constructor

I'm dealing with that issue right now, and the best I can see to do it put it in the docs "Don't use New"


sebas76(Posted 2009) [#61]
+1
I want also pass parameter into the constructor New:


Type MyClass
Field a:Int
'...

Method New(b:Int)
a = b
End Method
End Type

Local instance:MyClass = New MyClass(10)

We need method overloading...
I hope Mark sibly is reading this post...


Brucey(Posted 2009) [#62]
For wxMax, I generally expose two constructors :
Function CreateButton:wxButton(parent:wxWindow, id:Int, label:String = Null, x:Int = -1, y:Int = -1, w:Int = -1, h:Int = -1, style:Int = 0)

Method Create:wxButton(parent:wxWindow, id:Int, label:Object = Null, x:Int = -1, y:Int = -1, w:Int = -1, h:Int = -1, style:Int = 0)


The second is useful if you are subclassing the widget, because, used with New, you can do this :
Type MyButton Extends wxButton

   Method SomeOverriddenMethod()
   End Method

End Type

Local button:wxButton = New MyButton.Create(....)

which will call the wxButton constructor, and do all the necessary low-level library stuff, but give you an instance of MyButton and allow the framework to call your overridden methods transparently.


Brucey(Posted 2009) [#63]
Okay... so you want to pass parameters into New() ?

How do you handle this :
SuperStrict

Framework brl.standardio

Type Parent

	Field _a:Int

	Method New(a:Int)
		_a = a 
	End Method
	
End Type

Type Child Extends Parent

	Method New(a:Int)
		' this way ?
		_a = a ' code duplication
		
		' this way?
		Super.New(a) ' um... no... given the result of the following example.
	End Method

End Type

New Child


given the result of this :
SuperStrict

Framework brl.standardio

Type Parent

	Method New()
		Print "New Parent"
	End Method
	
End Type

Type Child Extends Parent

	Method New()
		Print "New Child"
	End Method

End Type

New Child


...answers on a postcard to...


Czar Flavius(Posted 2009) [#64]
Add private/public methods (for New) and you can fix the problem with your own constructors that cannot be bypassed :D


Kurator(Posted 2009) [#65]
@brucey:

Fakin a constructor method with _Init(), please assume it would be the Constructor :)
SuperStrict

Framework brl.standardio

Type Parent

	Field _a:Int

	Method New()
		Print "New Parent"
	End Method
	
	Method _Init(a:Int)
		Print "Assigning Field a"	
		Self._a = a
	End Method
	
End Type

Type Child Extends Parent

	Method New()
		Print "New Child"
	End Method
	
	Method _Init(a:Int)
		Super._Init(a)
	End Method

End Type

Local t:Parent = New Child

t._Init(4)


'a' is only assigned once, but in your first example I would suggest to call it not like "Super.New(4)" but as "Super(4)" - like in C# or Java


Tommo(Posted 2009) [#66]
How about "Private" section in type defination (just like Private/Public outside type defination)?

I find "Private" becomes a neccesary when you deal with a big project tree.
More than hiding details from final user, it can be used to seperate implementions and interfaces too.
By hiding unneccesary symbols from public, you can save quite much time from recompiling.


Htbaa(Posted 2009) [#67]
One thing not mentioned I believe are closures. I'd love to get those :-)


sebas76(Posted 2009) [#68]
But have we a chance to have some or all of this features included one day in bmax ?


jsp(Posted 2009) [#69]
hope dies last


SLotman(Posted 2009) [#70]
+1 for method/function/operator overloading!

as to

Function <T:Object> Max:T(x:T, y:T>
   If(y < x) Then
       Return(x)
   Else
       Return(y)
   End If
End Function


I prefer the VB5/6 method: create a new data-type called Variant.

So you declare:
Function Max:Variant(x:Variant, y:Variant)
  If (y<x) Then Return x Else Return y
End Function


Then you can even use it like s1$=Max("hey!","ooops!") - and it will work!

The best is that it would even work with SuperStrict, Strict, etc - since it would just be a new data type.


Htbaa(Posted 2009) [#71]
Variant seems like a much more cleaner solution than C++ style templates.


Dreamora(Posted 2009) [#72]
Not really, it does not guarantee any direct visible type upon which you can rely for the type safety when writting code. thats not exactly supportive.

Prefer the Eiffel - C# approach with their generics.


Czar Flavius(Posted 2009) [#73]
Hey, Varient is just my Symbol idea renamed!
What about this, where you can specify what types can be used with the varient. It can be checked at compile-time so won't slow anything down at run time.

Varient number
	Byte, Short, Int, Long, Float, Double, TCustomNumberTypeForExamplePurposes
End Varient

Function Max:number(x:number, y:number)
  If (y<x) Then Return x Else Return y
End Function

Now you can have different kinds of varient in the same function if you wanted to. (The custom type I included presupposes operator overloading, just to be cheeky)