I've tried to make parts of systems I build fit into classic OOP type design and it always feels so awkward and rigid...
Even with multiple inheritance it doesn't make sense to say "this thing's parents do this therefore it does this". Isn't it more natural to say "this thing has these properties therefore it can do these things". It seems more composable and less locked down. I think this is known as "traits".
For example, for a GUI library, instead of saying:
a "Slider" is descended from a "DraggableControl" is descended from a "Control" is descended from a "Window" class
wouldn't it be nicer to define it like:
if an object has a "handle" property then it can run this "Drag" method
Does anyone have experience with using traits or similar ways of designing systems?
Traits should be good too, but I have little knowledge about them, mostly because `trait' gets a new meaning/implementation similar but different to the others every week.
>>1
Data-oriented design, which is a superset of functional programming. You focus on coming up with the optimal formats for your data that are most efficient for the CPU and memory controller and then compose functions/operations that transform the data from one end of your system to the next. Throw in some macro/generic programming on top for compile-time polymorphism. And use a bit of OOP if you have to for where it makes sense. Confining yourself to a single paradigm, ie. forced OOP in Java of example is brain-damaging.
Lisp, Scheme, Go, C, and C++ all support data-oriented.
>>4
Stop fooling yourself, you can do it in almost any language that supports raw access to buffers. It's really all about whether the programmer understands those concepts.
Name:
Anonymous2011-08-10 14:14
alternatives to class-based design
I use simple ASSOC lists, merged from bunch of prototypes.
They aint good for code structuring, but do object modelling pretty well.
Name:
Anonymous2011-08-10 14:59
>>6
they're more complicated than just having functions that shunt things into ducks.
Name:
Anonymous2011-08-10 15:45
Hopefully Javascript will start getting more libraries ported to it so as to do GUI programming with prototype OO. This might happen when node.js gets ported to windows. Such a great language has languished with crippled browser I/O for too many years
Name:
Anonymous2011-08-10 15:54
>>10
I'm afraid Javascript is a terrible and broken language. Simple example: 15.9.2.1 Date ([ year [, month [, date [, hours [, minutes [, seconds [, ms ]]]]]]])
All of the arguments are optional; any arguments supplied are accepted but are completely ignored. A string is created and returned as if by the expression (new Date ()).toString().
Name:
Anonymous2011-08-10 16:30
joh joh joh /prog/ is so fresh against /prog/ reddit looks like a rat
Yeah, UI hierarchy was a great example of where it seems the tool itself makes the task more challenging.
However it is possible, in all cases, to design a hierarchical class system that functions in a reasonably organized way. We have, after all, decided to implement just such a taxonomy for all known life on our planet; it would be difficult to imagine doing so with something so nebulous as "roles".
A program is an improvisational narrative that is only finally told when it runs. Programmers obsess over defining nouns because they feel this what they can certainly control; however, it is the actors who appear and speak your lines. Better, then, to command your actors specifically, directly, and in the moment, rather than cast actors whom you hope will interpret the script the same way you would, by rigorously narrowing your definition of what an "actor" is ahead of time, according to your imagined ideal performance, which is all of course, specific to your play, and moreover, your arrangement of your play, which amounts to predictions of predictions: the "safer" way, they said.