Hidden methods

BlitzMax Forums/BlitzMax Beginners Area/Hidden methods

QuickSilva(Posted 2009) [#1]
Recently I discovered that TImage has lots of methods that I did not know anything about as they are not listed anywhere in the program that I can see.

You can do things like MyImage.Width for example. How is a beginner to BMax supposed to find out about these things using the default IDE? I cannot even find the methods in the BMax source code, there obviously in there someplace.

How do you guys find about about things like this when using the default IDE? Have I missed something or are there just some important omissions in the docs?

I do not mean to moan as otherwise I think BMax is a great product but I feel like I`m always missing out on some cool features that this language contains. TMaps for example seem really helpful yet I`d never even heard of them until recently. I`m sure that many other beginners here are struggling, I`ve even thought of returning to B3D because of this which would be a great shame.

Jason.


GfK(Posted 2009) [#2]
Simple answer? I don't use MaxIDE. I use BLIde.

Its intellisense is by far the easiest way of finding out what methods/props are available for any given object.

MaxIDE is OK, in the same way that somebody who has one of their legs amputated would find a pair of crutches "OK". Of course, a new bionic limb (or a more featured IDE, in this case), would make life a lot easier, ultimately.

However, some people are happy to struggle onwards with a stick under each arm, not wanting to go through the process of learning something new, even if it would be better for them in the long term.


Brucey(Posted 2009) [#3]
However, some people are happy to struggle onwards with a stick under each arm, not wanting to go through the process of learning something new, even if it would be better for them in the long term.

That must be me then... Just call me Hobble.

I suppose it also depends how curious one is. For example, I'm happy to go rummaging through the source-code for all the modules - simply because they are there.
Of course, when you do that, you come across things and wonder "why did Mark do it like that!?! If he'd done it like he did with that other module, it would make it much easier to extend...." . The price of being nosy, I suppose.

You can do things like MyImage.Width for example

Except that width is field, not a method :-)


Mark Tiffany(Posted 2009) [#4]
You can do things like MyImage.Width for example

Or just use the documented command ImageWidth ???


Brucey(Posted 2009) [#5]
That too :-)


plash(Posted 2009) [#6]
Aye, the best way (without lots of documentation), is to just read the code for the modules! (and you should also get a very good understanding of how things work)


ImaginaryHuman(Posted 2009) [#7]
Image.Width is a Field, not a method.

You can access fields directly like that. However, part of BRL's design (I think) is that they would prefer you don't directly access fields. It's supposedly not object-oriented enough, because if they go changing the Image type in the future, maybe renaming some fields or changing what they mean, it would break your code. That's why they often have things like ImageWidth() to `get` the field in a standard consistent way. Ie the interface to the type is a consistent API for the programmer and you shouldn't be worried about what goes on under the hood. But that said, most of BlitzMax is probably pretty stable and fixed by now so you can probably use .field access pretty safely.


Wiebo(Posted 2009) [#8]
If BRL was serious about that, real 'private' fields and methods would've been implemented. One of my personal wish list items!


Beaker(Posted 2009) [#9]
ImaginaryHuman is mistaken. ImageWidth exists for beginners, and those moving over from Blitz3d (or other). If Mark changed the name of a field at this stage it would not only break our code, but also much of his own!


Who was John Galt?(Posted 2009) [#10]
I just use an underscore in front of my fields to indicate private ones. Seems a very clean way of doing it to me.
field publicpart
field _privatepart


It makes code inside methods with an 'implied private' very readable.
method setx(x#)
       _x=x
end method



Wiebo(Posted 2009) [#11]
Mark does the same, and I've adapted it too. It's a nice reminder of what's private and what not. As a rule, I never access fields marked with _ from outside the type.
But it's a workaround for something most of us would love to have in the language.


Who was John Galt?(Posted 2009) [#12]
Mark does the same, and I've adapted it too. It's a nice reminder of what's private and what not. As a rule, I never access fields marked with _ from outside the type.
But it's a workaround for something most of us would love to have in the language.
Fair point. I can't argue with that.


Mark Tiffany(Posted 2009) [#13]
Mark does the same, and I've adapted it too. It's a nice reminder of what's private and what not. As a rule, I never access fields marked with _ from outside the type.
But it's a workaround for something most of us would love to have in the language.

Agreed - and I'm not convinced it should be too hard to implement...surely the Private / Public keywords should just trigger bcc not to put the field / method / function definitions in the .i files???


Otus(Posted 2009) [#14]
Agreed - and I'm not convinced it should be too hard to implement...surely the Private / Public keywords should just trigger bcc not to put the field / method / function definitions in the .i files???


I thought the same and actually tried to write a BMK wrapper to strip them some time ago. However, IIRC, the order and number of fields and methods in interface files (.i) matters. Reordering public ones first (in source) does not help much either, since another module may need to extend and add slots. The only way I came up with was to rename the private members to something like "_reserved1"... but is that really any better than currently?