What's the difference between this code?

I was wondering the difference between Function and Method when used in the following specific manner. I can't really see a difference because they both work the same when used like this.

Type Blah
   Field a:Int

   Function Add(this:Blah)
      self.a :+ this.a
   End Function
end type

and

Type Blah
   Field a:Int

   Method Add(this:Blah)
      self.a :+ this.a
   End Method
end type

Does the first one run?

The second example makes sense to me, but in the first one, what would 'self' refer to?

'method
blah1.add(blah2) <- 'self' in add refers to blah1

'function
Blah.add(blah2) <-Blah is type, not instance.

Yep you're right. You can't use self in a Function. I was only asking because I was poking about in the TQuaternion.bmx file from MiniB3D. I saw that simon was using Function in the Type and I guess I didn't look close enough at what the function was doing.

You can't use self in a Function

Yes you can.
You can use self to call any type specific functions and globals.
What the problem is with the first example, is that you are using self in a function trying to access an INSTACE specific field. And Functions dont have INSTANCE specification.


(Also , probably doesnt matter, but using "this" in "self" examples is a bit confusing)

You can often (always?) get away without using self, in type methods (and probably functions)
e.g:

a:+this.a

is shorthand for

self.a:+this.a

I agree that you can nearly always not use it, but if you are using BLIDE (for examle), a "self." is really useful cos then you get a list of all the members of the type.
Quite early in using BLIDE I did a speed test, and posted a few questions, and it doesnt slow down the code.

However several ppl said it made it harder to read, although now that I do it all the time, it seems easier to read to me

right now, you can use self in functions, its a bug in the compiler.

With 1.26 an onward you won't be able anymore. There is no instance that the function is called from, therefor self is always 0 and will bomb.
Don't use self and just call the function name (unless you have different scopes with the same, then use Typename.Functionname) if you don't want to rewrite your code in the future.

Well I dont think it should be removed.

Self in a function does at present, and still should in future represent the type name when called from an function.

That is

Function MemberofAType()
    self.AGlobalMember
EndFunction

Should be the same as

Function MemberofAType()
    AType.AGlobalMember
EndFunction

That is the way Bmax uses Self IS BETTER than "This" and only ppl who think it should work like "This" consider it a Bug.

I see no reason at all why it should be changed
But why change self at all, if all its going to mean, is that some people are going to have to change there code?

Fair enough there might be a good reason for it not to be the way it is. But if the only reason is "It wasnt supposed to work like that", then that isnt a good enough reason

now, right now, self represents in a function the same as in a method and thats an error.

with self within a function you can actually call METHODS on that object as well as fields, if you call it like object.someFunction.

Function are clearly specified as "global and existing on type level". On type level there is no self in a function (self is the calling object, a function does exist on class level not on object, so there is no calling object just a calling class) and there never should be.

So why can we not simply redifine "SELF", so that at Instance level ie Methods it works as its seems it was intedned, but at Type Level (Ie Not Methods), it works as it does now.

No you cannot. You will get a "Identifier not found"

I agree that there is a difference between the way SELF works, and the way SELF its documented to work. What I want to know is why not just change the documentaion, rather than the implimentaion, which in no way make programming or using self harder, and does in fact make some things easier

I agree with H&K, allowing Self to continue allowing access to type globals and type functions is much preferable to having it bomb for no good reason.

I agree with Gabriel and H&K. Besides which, semantically "Self" doesn't imply an instance (as opposed to This for instance).

Self is the "this" of C++ ...
Its a handle to the current object, which assumes that there is a current object which quite clearly prevents it from existing in Functions.

I would prefer a class keyboard, which is used to access global, const and functions (as there is the keyword super to access the superclass) and make self bugfree in the meaning of a pure "this" like reference to the current object a method is executed on.
Because right now it is a very bugged intermix sadly. Casting of Self for example is not possible but if you return self from a method, you can cast it, which just implies a core problem with handling of self.