Name is Alex Bradley, responsible for the KineticFusion AS2.0 compiler. Just a quick question. I'm attempting to test the new As2Lib with our compiler and I've run into a bit of a problem! This is not a bug per-se which is why I'm addressing this on the discussion pages instead. The problem is a name clash in the org.as2lib.data.holder package. There is a class called Map and a sub-package called map, similarly for list and stack. Which this does not cause any problems at all running on the Flash 7 player, ActionScript 2.0 is meant to be Flash 6 compatible. My understanding is that most of the Flash 6 player incarnations out there are not case-sensitive - hence the Map class and the map package both map onto exactly the same object. This will not work for Flash 6 and will result, in the best case, in the Map class getting all the subpackages classes attached to it as class members.
Am I reading this right? Currently our compiler is fully Flash 6 compatible which means that the only class/package clashes that are allowed are the intrinsic System and TextField class/packages. I haven't checked any of the other as2lib packages for clashes since our compiler refused to accept the above package.
The way that MM get around this is to suffix packages such as the map subpackage above with 'classes' i.e. the class is Map the sub-package is mapclasses.
I look forward to your response - I could alter our compiler to accept your layout but I think it's a mistake to ignore all the Flash 6 devices.
Cheers,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I partly agree with you that it is said that event classes that might be Flash 6 compatible cannot be compiled to Flash 6 because of possible problems resulting from lower or upper case.
The only way to fix this would be to put the "Map" class into the "map" package (or to rename the map package). What I do not like about this is that it makes writing the code less convenient. You normally only have to work with the interface "Map" which is in the "holder" package and must use the "map" package only to instantiate the specific class. It is a kind of package naming style/convention.
I cannot agree to renaming or moving the classes or packages right away. Need a little more considerations. But right now from my first impression I'm not willing to do this changes just for Flash 6 compatibility with some classes (and the data holder classes use reflections somewhere, so these will nevertheless not be flash 6 compatible).
If you have further good arguments that might convince me I'd be more then glad to hear them.
Greetings,
Simon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for expanding on that. And I can't think of any more arguments (never mind good ones)... !! I guess I'll add a modification to our compiler to permit these naming clashes for V7 SWFs.
Good work with As2lib - it's looking good.
Cheers,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, thanks for the response. But just to clarify - this is not a compiler issue, it's a runtime issue. The KineticFusion compiler currently restricts naming clashes to the very minimum allowed i.e. the ill-designed Macromedia System/TextField clashes.Do you not think it would be a idea to support the V6 player for the non-v7 specific classes?? The work involved in renaming 4 packages and altering their references is surely worth it, no? Or is the entire framework tied specifically to V7 features?
IMHO I also think it is a dangerous naming convention as a slip in case e.g. Map/map could have people iterating though al class object instead of a package etc. Is it not better to correct this now?
Cheers,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Name is Alex Bradley, responsible for the KineticFusion AS2.0 compiler. Just a quick question. I'm attempting to test the new As2Lib with our compiler and I've run into a bit of a problem! This is not a bug per-se which is why I'm addressing this on the discussion pages instead. The problem is a name clash in the org.as2lib.data.holder package. There is a class called Map and a sub-package called map, similarly for list and stack. Which this does not cause any problems at all running on the Flash 7 player, ActionScript 2.0 is meant to be Flash 6 compatible. My understanding is that most of the Flash 6 player incarnations out there are not case-sensitive - hence the Map class and the map package both map onto exactly the same object. This will not work for Flash 6 and will result, in the best case, in the Map class getting all the subpackages classes attached to it as class members.
Am I reading this right? Currently our compiler is fully Flash 6 compatible which means that the only class/package clashes that are allowed are the intrinsic System and TextField class/packages. I haven't checked any of the other as2lib packages for clashes since our compiler refused to accept the above package.
The way that MM get around this is to suffix packages such as the map subpackage above with 'classes' i.e. the class is Map the sub-package is mapclasses.
I look forward to your response - I could alter our compiler to accept your layout but I think it's a mistake to ignore all the Flash 6 devices.
Cheers,
Alex
Sorry, above should have read "queue and stack" not "list and stack" (don't think it let's me edit my own posts. Grrr).
The only other location for conflict is in : org.as2lib.env.log where there is a class Logger.as and a sub-package logger.
Hi Alex,
I partly agree with you that it is said that event classes that might be Flash 6 compatible cannot be compiled to Flash 6 because of possible problems resulting from lower or upper case.
The only way to fix this would be to put the "Map" class into the "map" package (or to rename the map package). What I do not like about this is that it makes writing the code less convenient. You normally only have to work with the interface "Map" which is in the "holder" package and must use the "map" package only to instantiate the specific class. It is a kind of package naming style/convention.
I cannot agree to renaming or moving the classes or packages right away. Need a little more considerations. But right now from my first impression I'm not willing to do this changes just for Flash 6 compatibility with some classes (and the data holder classes use reflections somewhere, so these will nevertheless not be flash 6 compatible).
If you have further good arguments that might convince me I'd be more then glad to hear them.
Greetings,
Simon
HI Simon,
Thanks for expanding on that. And I can't think of any more arguments (never mind good ones)... !! I guess I'll add a modification to our compiler to permit these naming clashes for V7 SWFs.
Good work with As2lib - it's looking good.
Cheers,
Alex
We use exceptions and some interface features of f7 player (things that will never work in f6 even in workarounds)
It is a mistake to ignore compiler/runtime environments but as there grow up so many of them we have to take restrictions.
This discussion reminds me to the "be Netscape 4.7 compatible or not"-discussion.
We choose ActionScript 2.0 - with all parts. Other view: We would ignore all the features of AS2 if we don't work with em.
I am not pro/against your thread - its simple illusionary to test it with f6 and multiple f6 compiler so ... well ... hmm ...
greetins
Martin.
OK, thanks for the response. But just to clarify - this is not a compiler issue, it's a runtime issue. The KineticFusion compiler currently restricts naming clashes to the very minimum allowed i.e. the ill-designed Macromedia System/TextField clashes.Do you not think it would be a idea to support the V6 player for the non-v7 specific classes?? The work involved in renaming 4 packages and altering their references is surely worth it, no? Or is the entire framework tied specifically to V7 features?
IMHO I also think it is a dangerous naming convention as a slip in case e.g. Map/map could have people iterating though al class object instead of a package etc. Is it not better to correct this now?
Cheers,
Alex