Class extension (dot syntax for new methods)

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

Koriolis

Yes you can, in fact, it works wonderfully. You may user moduleserver.modulename.function to access it.

OK, maybe i should have been clearer : it won't work unless you give an explcit scope. There is no reason why it would be different with extension methods, because extension methods are just plain functions.

Allowing 'outside the module' extension is the quickest way to break namespacing

When I ad a new function, it's necessarily outside of any other module. What's different with extension methods? Once again, extension methods are for the most part a simple syntax sugar that may even be implemented by a preprocessor. There are reasons not to like it (specifically, amking not obvious for huma reader when you call a real method, and when you call an extension methods), but 'namespace breaking"' is not one of them.

Well perhaps I totally your idea but:
Modules are compiled in a totally distinct step to the extension methods...

Indeed I think your misleaded here. Maybe a simple example will help to outline how simple and dumb the feature is.
Just think about the langauge that don't suport proper OO like BlitzBasic. In such languages, you can't do "Object Oriented Programmin", but you can do "Object Based Programming", such as in this example:

Type TBla
End Type

Function TBla_DoSomething(this:TBla)
...
End Function

Local obj:TBla = new TBla
TBla_DoSomething(bla)

Here we hare somewhat emulating the concept of methods. It is not a "true method" in the sense that you can't do any overriding, and yes indeed it's just a function. However you're thinking OO. Now, what if there was a syntactic sugar so that I could use this natural syntax:

bla.DoSomething()

It surealy feels more what you intended to do in the first palce. However it's still a pure syntactic sugar, because you still have a simple function (it's still a direct call, there is no dynamic dispatch, and no possibility of overriding). Extension methods are just that.
Given that it's just a plain function, I hope it's now clearer that there can't be much more technical problem than there is (or isn't) already with good old functions.

The problems: it produces non clean code as an object can be extended after it was "fixed" which would break programming by contract designs, it would allow to totally mess up the programming to interface designs and a few other problems).

Nope. You're not modifying anything in the existing contracts, so there's no problem. Being a simple funciton, an extension method is not supposed to ba able to bypass anything. Let's imagine for a second that BlitzMax supports private fields and functions, an extension method couldn't magically access these private parts any more than any other function. You don't touch anything in the original type itself.

In a sense, I can easily see why extension methods seem bad. We've learnt how important encapsulation and contracts are, and extension seem to break all that. The thing is they don't. At all.

Really, the one good reason for not liking extension methods is it makes calls more ambiguous for the human reader, in the sense that you may wonder if it's an extension method or a real method. I don't see any other reason.