[FlashCodersNY] 3. Consolidating my project's class files (Jeremy Sachs)

[Tim Beynart]

What exactly do you mean by "break into?"  What kind of security are you
looking for?
Public and Private are concepts for enforcing programming rigor, I never
thought of them as security mechanisms.


On Tue, Jan 13, 2009 at 10:19 AM, Jeremy Sachs <jeremysachs at rezmason.net>wrote:

>
> On Jan 13, 2009, at 5:24 AM, Will Saunders wrote:
>
>>
>>
>> Hey, I don't know if this was ever answered but I hadn't seen anything
>> more about it on the list so I figured
>> I'd chime in. Firstly, if you really care about controlling what people do
>> with your source, it might make more sense to compile (and maybe even
>> obfuscate) your code into a swc or however it's spelled. Fiddling with your
>> namespaces won't prevent anyone from fiddling with your code, they'll just
>> have to be a little more deliberate about where they fiddle. Though I
>> understand every little bit helps though, and the average person glancing at
>> your code would be deterred to some degree.
>>
>> For those times when I want to minimize fiddlalallitty, though, I use a
>> code based approach.
>> ...
>> This makes sense because the helper class is only available within the
>> file it's defined. You can write some sort of singleton/semaphor/one way
>> locking thingy that exposes one public function with which you get the
>> properly instantiated...um... instance. :) This will let you control when
>> and how your classes are initialized, but only to some degree :\
>>
>
> I've experimented with Singletons. They're handy when they're internal
> classes. But consider- if you reorganize your classes into multiple
> packages, you'll have no choice but to make your Singleton work in the
> public namespace. And that means giving the Enemy direct access to your
> class, regardless of what tricks you may do to the display list (which I
> ended up relying on). Ironically, I've had to revert some of my Singletons
> back to being regular classes, because it was more important to prevent
> unwanted access to the instance than to prevent multiple instances.
>
> I've got a question, though- you say that "fiddling with namespaces won't
> prevent anyone from fiddling with my code". Doesn't it limit the Enemy to
> fiddling with publicly declared classes, variables and methods? If we have
> this class,
>
> public class Giraffe {
>        private var _head;
>        private var _neck;
>        public var tail;
>
>        public final function get head():* { return _head; }
> }
>
> -the Enemy can only access _head (through the public getter) and tail, and
> cannot access _neck. By using the proper namespaces in the right places in
> the Giraffe class, can't I limit the Enemy's influence on Giraffe instances?
>
> Furthermore, if all my program's important instances of Giraffe are
> privately declared, and aren't passed through the public namespace, wouldn't
> that be enough? The only truly relevant information, I believe, that I'm
> forced to share with the Enemy in a public class is in publicly declared
> static variables and constants- which as I said is ironically the place
> where Singletons store their references to their instance.
>
> I wonder how much I'd learn if I just put my app online and dared Flash
> folks to break into it. It's a compelling idea at this point, because like
> user testing, there would be a greater chance at finding issues with the
> software.
>
> -Jeremy
>
> _______________________________________________
> FlashCodersNY mailing list
> FlashCodersNY at flashcodersny.org
>
> http://mail.flashcodersny.org/mailman/listinfo/flashcodersny_flashcodersny.org
>



-- 
+ Tim Beynart
+ tim at timbeynart.com
+ 706.372.6994
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.flashcodersny.org/pipermail/flashcodersny_flashcodersny.org/attachments/20090113/37decbd4/attachment.html>