Method Overloading?

Tch Tch Tch Guys.

What about Method Overloading?

The following code snippet should work in a true OOP programming environment:

Type Coords2D
	Field x, y
End Type

Type Dimensions2D
	Field w,h
End Type

Type Colour
	Field r,g,b
End Type

'Base abstract class for a basic gadget.
Type Gadget Abstract

	Field Name$

	'Position and size attributes.
	Field Position:Coords2D = new Coords2D
	Field Size:Dimensions2D = new Dimensions2D
	Field ZOrder
	
	'Behavior
	Field HasFocus
	Field TabOrder
	Field Visible
	Field Enabled
	
	Method Draw()	Abstract
	
End Type

'Simple Label Gadget
'------------------------------------------
Type Label Extends Gadget

	Field Text:String
	
        'First Static Create Method
	Function Create:Label(txt:String)
		Local lbl:Label = New Label
		lbl.Text = txt
		Return lbl
	End Function
	
        'Overloaded Static Create Method
	Function Create:Label(txt:String, x:Int, y:Int)
		Local lbl:Label = New Label
		lbl.Text = txt
		lbl.Position.x = x
		lbl.Position.y = y
		Return lbl
	End Function

        Method Draw()
           'Do something here
        End Method

End Type

Instead I get an error stating that the Create function is defined twice. I Do hope this is something that will be rectified in the future.

-Jim

me thinks you mean function overloading... although in java, they may refer to it as method overloading...



--Mike

Yeah. But in BMAX a function inside of a Type (or class) is the same thing as a Static Method in java.

It's cool, but can get confusing, particullarly in IDEs that don't have tooltip in-line signiture help (like the BlitzMAX IDE) or worse, has bad in-line signiture help (like VisualStudio).

Define "true OOP programming environmet"? It wouldn't work in Simula 67 (the mother of OOP languages) or SmallTalk (the other mother of OOP languages), in fact function overloading was first introduced in Ada nearly 20 years later.

While I agree that not having it is an oversight on behalf of BRL, I accept their reasons for doing so (even if I don't particularly agree with them).

I don't know whether or not it's going to be rectified in the future, nor do I believe it's nearly as important an oversight to recctify as the lack of "proper" access modifiers (which is one of the cornerstones of encapsulation, and thus an OOP methodology/language).

This has nothing to do with real OO just with lazy programmers.

Eiffel does not support function overloading as well and at the moment it is the purest form of OO designed by Bertrand Meyer whos book is used widely when it comes to OO design teaching.

it has good reasons why it is not supported, one of them is that different headers have a different use so a good designed OO system should assign different names to it as well as it is a different feature.


So just because it works in C++ or languages that evolved out of it or were inspired by it, it does not mean that it is something that should really work in a real, safe and correct OO language

I used to hate Function Overloading, then I started finding uses for it over time. Now that I'm using BMax, I've run into a few situations that FO would have been nice to use, but I can't.

To me it would be nice to have this feature, it probably wouldn't take that much effort to implement on Marks part, and would be optional. So if you didn't like the feature, you wouldn't be forced to use it.

For those of us who do find it useful, we would be able to use it.

If Mark doesn't think it's worth the effort, then I'll live without it.

I stand corrected on the "True OOP Environment Statement". Thanks for keeping me in check about that.

But how can Function/Method overloading be attributed to lazy programmers?

Wouldn't it make sense if you have multiple ways to carry out the same task, but each method requires different data to do so, that they should all be called by the same name? They aren't different features, they're the same feature.

Sure I could have created a function called:

Function Create()

And another function called:

Function CreateAndAssignValues(val1, val2,...)

But that's just sloppy and cluttered code (IMHO).

I love Function/Method overloading because it helps you clarify the specific functionality of your code.

A class should only have one 'Create' function/method IMO. But there s/b more than one way to create the object (if the situation so requires it).

Sometimes you may need to create an object and assign values to it later, other times you may need to assign values to an instance of the same object at the point of creation. Sometimes you may need to create a new instantce of the same object and assign different types of values at the point of creation.

You are all right. Itt IS a matter of choice. But I think that Method/Function overloading just leads to easier to read/understand code (IMHO).

I've been spoiled by doing Java and C# development over the past several years.

I'm really likeing what I'm seeing with BMAX. Can't wait for the official Windows release, and the 3D module. I like the fact that it's an easy to use Object Oriented programming language that isn't compiled to some byte code.

-Jim

I would like to have function and method overloading.

Mark did point out some possible complications, my response is that there would need to be some consistant rules for dealing with ambiguities.

based on my work with wrapping Irrlicht, the three biggest things i missed were constructors with parameters, method overloading, and manual deletion of variables.

there is the ability to have a static create function which allows parameters, but the problem is that if you subclass, you always need to provide a new implementation because calling subclass.create() without overriding will give you an instance of the base class.

as CoderLaureate stated, as i was converting methods that were overloaded in C++, their definition became much less intuitive in BMX due to needing to have several create methods all named something different. i think this is more of a preference thing though.

maybe its there and i missed it somehow but this is the most import one IMO. being able to retain an object in memory after all reference variables have gone out of scope would be real nice. this could actually be simulated fairly easily (ya... easy for me to say anyway) by allowing direct access to the reference counter for an instance via 2 functions, RefInc(obj:Object) and RefDec(obj:Object).

for example, some psuedocode could be:

Local obj:Object=new Object ' internal ref counter now at 1
Local objptr:Object Ptr

objptr=Varptr(obj)
RefInc(obj) ' manually increment ref counter so its 2

obj=Null ' ref counter back down to 1
FlushMem

objptr[0].ToString() ' its still there!!!

RefDec(objptr[0]) ' decrement the counter to 0
Flushmem ' bye bye

objptr[0].ToString() ' boom.  its now totally gone.

yes giving access to the ref counter opens the sytem up to leaks if the counter is not manipulated correctly, but i think taking that risk is worth it. most of the time the garbage collection would be used anyway, but if need to do something special you could.

hmmmm. im on to something here. i came across the Release function. the manual states:

Release removes the internal reference caused by creating an integer handle to a type.

sounds to me like setting an integer to a type increments the reference counter and Release is used to decrement that. will look into it further.

Release is only for procedural programming where you don't use :Type but let everything beeing converted to int because they are not handled by the garbage collector.

you can't access their methods as well so you will have to write "flat functions" to access such stuff.

thx Dreamora. how would you convert it into something usable?

nm... i figured it out. sorry folks waiting for the Irrlicht mods :) if this works out the way i want it to its gonna delay me another couple days! but it will be worth it :)

Well it's one opinion.

Well in that particular case, and provided all your parammeters are objects, (or if simple datatypes, wrapped in objects) you can fake it fairly convincingly in BlitzMAX as it allows you to specify "default" values:

Method myMethod:aType(param1:object = Null, param2:object = Null)

It's not "proper" function/method overloading, but it might work for you. Object should ideally be a reference to an interface, rather than a concrete class (which I'm sure you know).

It depends on how it's used, and while I find myself seldomly needing it, I can certainly see why you would want it.

Personally I'd want access modifiers and runtime reflection first. Please. :o>

So you think:

function create:bla ()
 return new bla
end function

function create:bla (x:int,y:int)
 t:bla = new bla
 t.x = int
 t.y = int
 return t
end function

is more readable than:

function make:bla ()
 return new bla
end function

function make_from_coords:bla (x:int,y:int)
 t:bla = new bla
 t.x = int
 t.y = int
 return t
end function

the first one is just shorter -> for lazy programmers as mentioned above.
But it is harder to read and even harder to proof stuff on the software system created with it.
-> not modern OO actually.

IMO, I prefer the first option, not to be lazy but I think its more elegant.

But its really just a matter of opinion.

it doesn't really matter... much :)

the first example is actually more preferable to me as well though... one function does it all... no cluttering up the lib with a million custom taylored ways of doing what is basically variations of the same thing... (what am i saying here :) ya still gotta write out the overloaded functions... sorry, not quite awake yet)


of more interest to me is what gman said above... the lack of constructors that take params... that come in very usefull, as i'm doing an object oriented framework for games on top of the 3Impact engine, and i find myself using them all the time...

question though... for all the seasoned c++ hackers... is this a 'correct' way to make a class...

--Mike

Absolutely. Frameworks such as Qt (the backbone of many modern Linux apps) use this extensively.

Well, it's not incorrect as such, more like deprecated.

I wander about this:

Type TestType
	Field Name$
	Field x%, y%
End Type

Function SetValues(obj:TestType, MyString$)
	obj.Name$ = MyString$
End Function

Function SetValues(obj:TestType, MyString$, x% = 0, y% = 0)
	obj.Name$ = MyString$
	obj.x = x
	obj.y = y
End Function


newobj:TestType = New TestType

SetValues(newobj, "My name") ' Which function would be called in a OOP language with function overloading?

I wander which function would be called in a OOP language that supports Function overloading, as the x and y values are optional parameters for the second function.

I would rather do this, as it would make debugging a lot easier:

Type TestType
	Field Name$
	Field x%, y%
End Type

Function SetValues(obj:TestType, MyString$, x% = 0, y% = 0)
	obj.Name$ = MyString$
	If x <> 0 Then obj.x = x
	If y <> 0 Then obj.y = y
End Function


newobj:TestType = New TestType

SetValues(newobj, "My name")

Depreciated in what sense? What are the alternatives?

Guys,

What are you talking about, overloading being depreciated or not modern OO - and lazy? I'm not advocating overloading in any way, shape or form, but your arguments are simply incorrect.

Have you taken a look at Delphi or .Net? .Net uses function overloading all throughout the BCL (Base Class Library). The Delphi VCL uses function overloading too. Both of these are neither C++/C or depreciated frameworks and are very object oriented in design. Sure they have their floors, but overloading is not one of them.

Convert.ToUInt64 has about 18 overloads. Also it is safe. C# does no explicit casting, so you know that your byte will only be called by the method taking a byte parameter, or a compiler error will result. You must explicitly cast. Even in C++ if there are ambiguities, a compiler error will result.

See Convert.ToUInt64 Method

Cheers,

Stu

Creation Design Patterns.

Only in constructor usage.



Yes. But ofcourse since .Net is heavilly tied into the underlying Win32 platform, it's hardly surprising it would inherit many of the same weaknesses as it's predecessor. Such a shame. When given the chance to make up their previos design errors/flaws - Microsoft decided not to take it.

Yes. And the only reason for that is because the .Net framework is strongly typed - you'll notice that had it not been, they would have only needed one 2, and if they could have used the default option parameter workaround, as mentioned above they wouldn't have needed it at all.

That does not make sense, whatever a 'creation design pattern' is, it cannot be an alternative to overloaded constructors if it requires an entire book to describe the technique and its uses. Moreover, the book you mentioned seems to be merely one approach to OO design (of which there are a great many), and nothing to do with C++ standards or guidelines. 'Depreciated' would imply that either it will be removed from the C++ standards in future, no longer supported by a compiler, or that it is no longer in widespread use. I dispute this.

I say add overloading. If you want to use it you can, if not, then don't. Simple as that. I know a great many people would like it, and others wouldn't. Just like some people prefer helper functions("ListSort(List)") to direct method access("List.Sort"). It should be an option. I for one think it makes code a lot easier to work with.

C++ and they way it works is about 20 years old.
The world has quite changed since then ...

professionals might have missed that but all that are educated nowadays learn real OO system design and not C / C++ "hack your programm" style

Flameduck,


Have you seen mono? This is successfully running on *nix - and is native, not requiring an API compatibility layer like Wine. I disagree with your generalisation that the whole framework is tied to Win32, given the success of mono.
How has method overloading got anything to do with Win32? This is a language function, not an OS or API function. I don't recall any overloaded functions in Win32. They use "Ex" style.



...and stronly typed is bad because of?
Had it not been strongly typed, and I did

Type MyType
  Field x, y, colour
End Type

Local tt:MyType = new MyType

Convert.ToUI64(tt)

This would compile, but I would get a runtime error. Not good for applications you distribute to businesses. Strong typing helps avoid silly issues like this.

Also, default parameters have nothing to do with the example I gave. My example shows good use of overloading. It is about passing a typed parameter in to a conversion function, and having the right method called.

Dreamora:

Education and real world are two different things, mate. I think your statement "the world has changed since then" should really be back by some real world experience. I have a degree in CS and what works or is taught in an institution certainly does not always apply. What is your argument that C++ is such a hacker style language? C++ is currently going through another revision and standardisation, and is certainly not "old".
One thing you will learn in the real world, is there is no single languge that will solve every problem. C++ has it's place. As does Delphi, Python, Tcl, NT Batch Commands, C#, Lua, Assembler, VB.Net, etc. Your attitude demonstrates your lack of experience.

Cheers,

Stu

You shouldn't be so quick to criticize a book you haven't read. The GoF book descibes more than creational patterns. It describes all of the original design patterns in great detail, including, but not limited to creational ones.

Well since we're talking about a general feature of OO languages (function/method overloading) and not C++ guidelines, I would have thought that was preferable. After all, C++ is just a "C-ified" version of Simula.

Wrong. Deprecated means, and I quote: "To express disapproval of; deplore". I couldn't care less about C++ standards - it's been well over a decade since I've actually wanted to use C++.

Yes I have. However since it's a .Net implementation, it's hardly surprising it would have the same functionality that .Net does.

Except it's actually a COM function.

I didn't say it was, nor do I want to get into a religious discussion about it. I merely pointed out that it has 18 overloads because the CLR is strongly typed.

Yes it would. Which is why traditionalists would argue that such operators should be overridden instead (ala. toString()).

No it doesn't. Your type implicitly extends object. Since there's an object overload to Convert.ToUI64 the problem is exactly the same.

Stu makes two very strong, good, and as far as i can see valid points...





--Mike

@Dreamora - function overloading can be considered 'lazy' in one sense - it makes life easier. Your preferred language must be machine code, unless, of course, you're 'lazy'.

Even the parts of Mono that are not found in MS' .NET implementation still use this feature. Saying that the usage of overloaded constructors in C# is a product of the underlying Win32 API is absurd.

No my language I use is Eiffel, as we use it for all educational courses ... and our head of SE Institute is Bertrand Meyer ... I think some here might know this name from references etc ... :)

It supports export mechanisms etc even C# 2.0 is dreaming of with its new generic support etc.

Yes. Well not being a member of the Mono or .Net design teams, I cannot say conclusively why they decided to go with the solution they did - I was just asumming it was because of limitation of COM - which seemed reasonable at the time, I was not aware that you where privy to any information I was not.

Perhaps it is because they considered it the best solution to the 'problem'.



Eiffel was created in 1985 and is pretty mature. There must be a flaw somewhere if it has failed to gain a large following, although I don't know the language well enough to say what it might be.

It does not really have any flaw beside the problem that it is an extrem work to get external libs working in it, even with .NET ...
This might be quite a large "breaker" for getting a broad userbase.

Its already used in many process critical stuff on which humans depend (aircraft 'software', health etc)

COM does not allow funtion / method overloading either - I think you are grasping at straws. :)

I agree with Robert, that they (Microsoft and external parties) no doubt went through many 'debates' like this, and decided that overloading was the most appropriate solution to the problem.

Cheers,

Stu

Like I said, I assumed it was because of COM. I was appearently mistaken.

What a horrible thought. I'm sure you're right tho'.

:) No worries. I think we made it through..

Cheers,

Stu