Juan Pablo Califano wrote:
I agree with you, but I'add for the sake of completeness that, sometimes,
relaxing the rules a bit becomes a necessary evil, like for instance, when
doing a cast.
I have another example of where a typecast can be useful. When you
really do need only BaseClass, but
Here's my code which uses the SharedObject to implement a User Data Manager.
This is my first ActionScript of any usefulness.
ja
http://vispo.com
package
{
// This is for managing the user's state from session to session.
// This saves their preferences and current state.
import
Simple and gloriously concise example (as opposed to mine!). Here, whether
the classes are native, or whether they are concrete instead of interfaces
won't change the need for a cast; all the involved objects have
commonalities but also important differences, and you want to treat them
public function x(y:* = null):void
{
}
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Jim Andrews
Sent: maandag 7 juni 2010 12:41
To: Flash Coders List
Subject: [Flashcoders] problem with strongly typed
public function x(y:Object):void
{
}
or
public function x(y:*):void
{
}
hth
jc
On Mon, Jun 7, 2010 at 12:40 PM, Jim Andrews j...@vispo.com wrote:
i want to write a method x which takes an argument y. i cannot anticipate
what type the argument is going to be until run-time. it might be a
Architecturally speaking, that's a bad idea. There's probably a strongly typed
solution to what you're doing. Can you provide detail about what you need to
accomplish so we can help you figure out a better solution?
On 6/7/2010 3:40 AM, Jim Andrews wrote:
i want to write a method x which
: Re: [Flashcoders] problem with strongly typed actionscript
Architecturally speaking, that's a bad idea. There's probably a strongly typed
solution to what you're doing. Can you provide detail about what you need to
accomplish so we can help you figure out a better solution?
On 6/7/2010 3
Patrick Matte wrote:
public function x(y:Object):void
{
}
Or this
public function x(y:*):void
{
}
Or, you can simply turn strict mode off. I tend to agree with Steven
Sacks, though. There's a really good reason for strong typing--mainly,
it's easier to find bugs at compile time than
Or, you can simply turn strict mode off. I tend to agree with Steven
Sacks, though.
There's a really good reason for strong typing--mainly, it's easier to
find bugs at compile time than at
Yep. IMO, there should never be a reason to turn strict typing off, it's
like saying, Don't tell me about
or maybe he is just writing a custom logger and wants to be able to pass any
type of object ;)
On Mon, Jun 7, 2010 at 9:44 PM, Merrill, Jason
jason.merr...@bankofamerica.com wrote:
Or, you can simply turn strict mode off. I tend to agree with Steven
Sacks, though.
There's a really good
-To: Flash Coders List flashcoders@chattyfig.figleaf.com
Date: Mon, 07 Jun 2010 11:38:07 -0700
To: Flash Coders List flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] problem with strongly typed actionscript
Architecturally speaking, that's a bad idea. There's probably
Architecturally speaking, that's a bad idea. There's probably a strongly
typed
solution to what you're doing. Can you provide detail about what you need
to accomplish so we can help you figure out a better solution?
i expect
public function x(y:*):void
{
}
will do the job.
the public
To: Flash Coders List flashcoders@chattyfig.figleaf.com
Subject: Re: [Flashcoders] problem with strongly typed actionscript
I send the same reply 8 hours ago, are my messages not coming through?:)
On Mon, Jun 7, 2010 at 9:05 PM, Patrick Matte
patrick.ma...@tbwachiat.comwrote:
public
Right so what you're essentially talking about is a Model, and the SharedObject
is acting as a Service.
public class Model extends EventDispatcher
{
private var so:SharedObject;
public function Model()
{
super();
init();
}
private function init():void
{
I agree with you, but I'add for the sake of completeness that, sometimes,
relaxing the rules a bit becomes a necessary evil, like for instance, when
doing a cast.
When you do this:
// bar is typed as ISomeInterface somewhere else
var foo:SomeConcreteClass = bar as SomeConcreteClass; // or
With due deference, what you just said I disagree with. The scenario you
described is not a necessary evil, it's a hack.
The only situation where that isn't a hack is if your class extends a native
type such as Sprite, but there's no ISprite. That problem is either solved by
adding the Sprite
Much obliged for your deference.
We would have to agree to disagree then, since I think I agree with you in
general terms, but you seem to disagree on this alleged agreement.
You say except for one specific case, the scenario I described is a hack.
Call it whatever you like. I might even agree
17 matches
Mail list logo
