PDA

View Full Version : MX04 - private member access


littleRichard
09-25-2003, 12:31 PM
ok i'm hoping someone can explain this to me because i just don't get it.

lets say i have this simple class:


class someClass
{
function someClass() {}

private someMethod():Void { trace("someMethod"); }
}


now on the main timeline i have this:


var myClass:someClass = new someClass();
this.myClass.someMethod();


this dosn't generate an error someMethod() gets called and traces to the output window even though it's private.

but if i try and access it like this


var myClass:someClass = new someClass();
myClass.someMethod();


it generates an error as i would have expected.

cheers,
rich

senocular
09-25-2003, 01:12 PM
its just the way the compiler handles the errors. Only if used specifically one way (without the this) then it will complain.

littleRichard
09-25-2003, 01:58 PM
hrmm....bummer.

so what's the point of having private members at compile time if they are only private when accessed without the "this" keyword? i mean it's the same friggin thing. if i declare something as private then it should be treated as private....ALWAYS:mad:

i was pretty excited about having private and public functionality. but now i'm thinking it's a total sham and won't be using it.

rich

senocular
09-25-2003, 02:40 PM
yeah they're not really private at all. strong typed values and private member access are only handles for the compiler - at compile time - for compiler error checking; and this only if you stick to that coding style and follow the "rules".

littleRichard
09-25-2003, 04:01 PM
yeah they're not really private at all.

yeah, i understand that. it's just for the compiler.

what kills me is that in my example i'm pointing to the same object either way but the compiler dosn't apply the same error checking either way. totally useless...

shrug....oh well:rolleyes:

thanks for the responses:)

rich

senocular
09-25-2003, 04:30 PM
yeah that does seem like it should be able to differentiate.
This actually came up before in another forum with the this thing (thats when I first realized that behavior). It concerned assigning a _visible property. The person having the problem was assinging 0 to _visible and getting a type mismatch error (as _visible should be boolean). Well when the poster posted the problem, they typed this._visible even though they were using just _visible. People tested this._visible and got no error, but _visible did produce the error.

My whole reasoning was that the compiler is preferable to AS2, and since this isnt used in referencing the object scope in AS2, the compiler kind of overlooks its usage and ignores potential errors from this-scoped properties. Whether or not that was a concious decision on MMs part or just neglect, I dont know.

littleRichard
09-25-2003, 05:17 PM
hheee...i acctually saw that thread yesterday but only really read the first post. serves me right:D

heres the link for anyone interested. it has lots of good tips http://www.kirupaforum.com/forums/showthread.php?s=&threadid=33950&highlight=visible+%3D+0

solari
10-06-2003, 06:54 PM
I cant believe it , I cant believe it . Ive been having the same problem and I thought it was due to some kind of problem with my flash player. .. .. I cant believe it.

Any one want to start a petition? I heard that mm knows that mx2004 is buggy and their going to release a patch for it. I bet if we put the pressure on theyll fix some of these things in the patch..

littleRichard
10-06-2003, 10:08 PM
their going to release a patch for it
Where did you hear that? I'd like to read it.


...Anyhow, I think the best thing you can do is send feedback to Macromedia.

senocular
10-07-2003, 09:35 AM
MM's been getting a lot of flak for it and they're being pressured enough as it is. I would be surprised if they didn't release some kind of patch though I havent heard any confirmation on that as of yet. They do definitely know of their problems and have been working to find patterns and isolate the issues - something which hasn't been easy for them to do apparently.

Nonetheless, this issue is not reallya bug. Its just behavior - how Flash works. They won't 'fix' it because its not broken. At least I doubt it. The whole this thing may be a little iffy, but otherwise, privates being not so privates and strict data types not being so strict is just the way things are. Basically, Im seeing this as a transitional period to what may be in future versions of Flash/Actionscript, something a little closer to what we were expecting with AS 2.0 this time around. I hope at least ;)

stealthelephant
05-16-2004, 02:52 PM
found this interesting while dredging thro the old pages.
also if u do the following

var myClass = new someClass();
myClass.someMethod();

it will access the 'private' member also, private in flash is more like protected in other languages

stephaneey
06-03-2004, 02:04 PM
Hello guys,

In the same order of idea, there are troubles with static and dynamic classes. Normally, if you don't use a dynamic class, you shouldn't be able to add methods or properties to the class via the instance but flash allows it.

See here:

class myclass{
function myclass(){
//just an empty class for the example
}
}
in a FLA file:

var obj=new myclass();
obj.myOwnProp=1;
trace(obj.myOwnProp);

---> accepted

However

var obj:myclass;
obj.MyProp=1;

Refused.

I think that we can pull out a conclusion from those examples. When not using strong typing, all the new implementations of Macromedia are not respected.

Annoying, isn't it?

hangalot
06-04-2004, 05:36 AM
mesh said @ a MM usergroup 7.2 is in the pipeworks 4 real soon, and that MM know they f*cked up in this product by releasing it. so...

senocular
06-04-2004, 07:43 AM
mesh said @ a MM usergroup 7.2 is in the pipeworks 4 real soon, and that MM know they f*cked up in this product by releasing it. so...

thats good news :)