NewsForumsCodeLogsGallerySpecsSearch

What's the difference between this code?

BlitzMax Forums/BlitzMax Beginners Area/What's the difference between this code?

Chroma(Posted 2007) [#1]
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



Who was John Galt?(Posted 2007) [#2]
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.


Chroma(Posted 2007) [#3]
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.


H&K(Posted 2007) [#4]
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)


Who was John Galt?(Posted 2007) [#5]
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


H&K(Posted 2007) [#6]
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


Dreamora(Posted 2007) [#7]
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.


H&K(Posted 2007) [#8]
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
unless you have different scopes with the same, then use Typename.Functionname) if you don't want to rewrite your code in the future
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


Dreamora(Posted 2007) [#9]
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.


H&K(Posted 2007) [#10]
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.

with self within a function you can actually call METHODS
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


Gabriel(Posted 2007) [#11]
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.


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


Dreamora(Posted 2007) [#13]
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.