I'm also at the point where I want to establish 'best prectices' before I rewrite all of my stuff. And I've had my doubts about the utility of OOP in Flash. It seems to create a lot of extra work. But then again, AS1 had its drawbacks too.

Having read through the various articles you linked to ("OOP Oversold", etc.), I was intrigued by the concept of 'Table-Oriented Programming.' But frankly, I have no idea how it would work in Flash. Do you?

You mentioned that 'you and your friends have been thinking a lot about the way you work, code and structure applications.' What have you come up with? Does Table Oriented Programming factor into it? I'd love to hear your thoughts.

Thanks for the thought-provoking articles.

Jim Kremens
jimkremens@reelscore.com

I'm also at the point where I want to establish 'best prectices' before I rewrite all of my stuff. And I've had my doubts about the utility of OOP in Flash. It seems to create a lot of extra work. But then again, AS1 had its drawbacks too.

Having read through the various articles you linked to ("OOP Oversold", etc.), I was intrigued by the concept of 'Table-Oriented Programming.' But frankly, I have no idea how it would work in Flash. Do you?

You mentioned that 'you and your friends have been thinking a lot about the way you work, code and structure applications.' What have you come up with? Does Table Oriented Programming factor into it? I'd love to hear your thoughts.

Thanks for the thought-provoking articles.

Jim Kremens
jimkremens@reelscore.com

the thing is the seperation between view and controller as in classic mvc/mvp isn't really necessary, and especially in Flash/ActionScript... where your view and presenter/controller are essentially tied to the movieclip.

i follow a Model/UI archi (as in java's Swing), with the UI dealing with both controller/presenter and view methods, and I find that a ton simpler and cleaner.

granted, there could be (and in fact are) special cases where the separation makes sense, but for the most part, the supposedly loose coupling created as a result of separating them is just a facade... you just create a set of extra (and i'm even tempted to say uneeded) methods, which are inherently tied to the original methods in the veiw, in the controller/presenter.

as to the merits of OOP/OOA&D... well its been belabored enough; i'm yet to hear anything that even comes close to being an argument... everyone who dabbles in our world, uses OOP/OOA&D and knows what he/she is about knows it is effectively a primitive in itself used to achieve other ideas such as those espoused in design patterns and the like. you also know OOP makes broad use of procedural/relational ideas... how else could methods/behavior be realized? as programmers we have to deal with the idea of 'primitives'.OOP allows us to redefine what primitives are on a per program/project basis.

if u do _real_ OOP/OOA&D, you know what you've got... and you know it's good ... if procedural works for you, by all means, stick with it... not only that, write such articles as "OOP Oversold"... don't forget to add the exclamation mark... who knows? you might even generate a good following
eokyere

the thing is the seperation between view and controller as in classic mvc/mvp isn't really necessary, and especially in Flash/ActionScript... where your view and presenter/controller are essentially tied to the movieclip.

i follow a Model/UI archi (as in java's Swing), with the UI dealing with both controller/presenter and view methods, and I find that a ton simpler and cleaner.

granted, there could be (and in fact are) special cases where the separation makes sense, but for the most part, the supposedly loose coupling created as a result of separating them is just a facade... you just create a set of extra (and i'm even tempted to say uneeded) methods, which are inherently tied to the original methods in the veiw, in the controller/presenter.

as to the merits of OOP/OOA&D... well its been belabored enough; i'm yet to hear anything that even comes close to being an argument... everyone who dabbles in our world, uses OOP/OOA&D and knows what he/she is about knows it is effectively a primitive in itself used to achieve other ideas such as those espoused in design patterns and the like. you also know OOP makes broad use of procedural/relational ideas... how else could methods/behavior be realized? as programmers we have to deal with the idea of 'primitives'.OOP allows us to redefine what primitives are on a per program/project basis.

if u do _real_ OOP/OOA&D, you know what you've got... and you know it's good ... if procedural works for you, by all means, stick with it... not only that, write such articles as "OOP Oversold"... don't forget to add the exclamation mark... who knows? you might even generate a good following
eokyere