I am think of making a library called "object" which would contain all of the *_argument.pd objects, and have objects for writing objects, things like objects for writing dynamically generated objects, meta data handling, etc.
Anyone object to the name "object"? ;)
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
I am think of making a library called "object" which would contain all of the *_argument.pd objects, and have objects for writing objects, things like objects for writing dynamically generated objects, meta data handling, etc.
Anyone object to the name "object"? ;)
yes
On Apr 6, 2006, at 7:15 PM, carmen wrote:
I am think of making a library called "object" which would contain all of the *_argument.pd objects, and have objects for writing objects, things like objects for writing dynamically generated objects, meta data handling, etc.
Anyone object to the name "object"? ;)
yes
Would you like to elaborate on that?
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Would you like to elaborate on that?
i'd just rather not see a bunch of workaround hacks packaged with the 'object' prefix, i think it should be reserved for something builtin. for an example of this, see Ruby's "Object" object..
diagram of the day: http://rhg.rubyforge.org/images/ch_object_classtree.png
On Apr 6, 2006, at 11:13 PM, carmen wrote:
Would you like to elaborate on that?
i'd just rather not see a bunch of workaround hacks packaged with the 'object' prefix, i think it should be reserved for something builtin. for an example of this, see Ruby's "Object" object..
diagram of the day: http://rhg.rubyforge.org/images/ ch_object_classtree.png
Pd is not an object-oriented programming language, so a classtree is totally irrelevant. There is no inheritance whatsoever, for example.
I don't think that Pd should have inheritance, its a totally paradigm. We should think of it that way. Its as Object-Oriented as any procedural language.
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
On Fri, 7 Apr 2006, Hans-Christoph Steiner wrote:
Pd is not an object-oriented programming language, so a classtree is totally irrelevant.
There are things that are both called OOP and don't have classes. (http://en.wikipedia.org/wiki/Self_programming_language)
There is no inheritance whatsoever, for example.
Chances are that one of my next externals is going to be called [super]. Half of the reason why PureUnity is on hold is because I need multiple inheritance but I don't know how yet.
Its as Object-Oriented as any procedural language.
I've got a problem with that taxonomy. I'd rather say that almost all OOP languages are procedural: that is because the concept of method is an extension of the concept of procedure.
Even putting PureData in the dataflow category is debatable, because there's too much dependency on execution order (not really because [t] exists, but because [t] has to be used so often!).
I don't think that Pd should have inheritance, its a totally paradigm.
I don't think that people should have paradigms.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, Apr 07, 2006 at 05:25:41AM -0400, Mathieu Bouchard wrote:
On Fri, 7 Apr 2006, Hans-Christoph Steiner wrote:
Pd is not an object-oriented programming language, so a classtree is totally irrelevant.
There are things that are both called OOP and don't have classes. (http://en.wikipedia.org/wiki/Self_programming_language)
So? That isn't at all why Pd shouldn't be considered OOP. Puredata doesn't even properly support this type of 'copy-and-modify' inheritance that Self and Javascript do. A save operation is required in between, and then if another save operation is performed all "objects" of the same "type" are modified. It's a very different behaviour to those two languages.
I've got a problem with that taxonomy. I'd rather say that almost all OOP languages are procedural: that is because the concept of method is an extension of the concept of procedure.
What is a method in Puredata?
I think it's best not to try and cram OOP concepts into this perfectly good dataflow language.
Even putting PureData in the dataflow category is debatable, because there's too much dependency on execution order (not really because [t] exists, but because [t] has to be used so often!).
The way Pd handles execution order makes it part of a subset of dataflow languages that also handle execution order explicitly. If you think that execution order has to be handled in one certain way in all dataflow languages then your definition is more narrow than mine.
That said, the name "object" is patently ridiculous given how generic a term it is. I would try and find something better (just incase Miller one day decides to crow-bar OO proper into Pd).
Best rgds,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Fri, 7 Apr 2006, Chris McCormick wrote:
On Fri, Apr 07, 2006 at 05:25:41AM -0400, Mathieu Bouchard wrote:
On Fri, 7 Apr 2006, Hans-Christoph Steiner wrote:
Pd is not an object-oriented programming language, so a classtree is totally irrelevant.
There are things that are both called OOP and don't have classes. (http://en.wikipedia.org/wiki/Self_programming_language)
So? That isn't at all why Pd shouldn't be considered OOP. Puredata doesn't even properly support this type of 'copy-and-modify' inheritance that Self and Javascript do. A save operation is required in between,
The "copy-and-modify" part of those languages isn't inheritance, it's construction: they don't have ordinary "constructors". They both support inheritance but they both don't use classes to do inheritance.
What I was trying to say is that there are assumptions made about OOP that are broken by some languages that happen to be very much called OOP; so the definition of OOP might be more flexible than what most think.
and then if another save operation is performed all "objects" of the same "type" are modified. It's a very different behaviour to those two languages.
No it's not: those languages have the "class" role played by ordinary objects: if you modify an object that is a "class" for other objects, those other objects immediately start behaving differently. That's even better than Pd because then, modifying code and applying changes doesn't need lose your settings: e.g. if [+ 42] is configured to add 37 instead, then changing the abstraction in a SELF-like way doesn't reset the changes.
I was not meaning Pd has particular affinities with SELF/Javascript but just that SELF/Javascript are good examples of things that are called OOP but breaks assumptions that people make about OOP.
Another great example of that is CommonLISP's CLOS library (and other such libraries it was based on): CLOS is both very different from SELF/Javascript and very different from every other OOP language/library. (note: CLOS is part of the standard library of LISP, but it's still just a _library_!)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, Apr 07, 2006 at 01:47:51PM -0400, Mathieu Bouchard wrote:
On Fri, 7 Apr 2006, Chris McCormick wrote:
On Fri, Apr 07, 2006 at 05:25:41AM -0400, Mathieu Bouchard wrote:
On Fri, 7 Apr 2006, Hans-Christoph Steiner wrote:
Pd is not an object-oriented programming language, so a classtree is totally irrelevant.
There are things that are both called OOP and don't have classes. (http://en.wikipedia.org/wiki/Self_programming_language)
So? That isn't at all why Pd shouldn't be considered OOP. Puredata doesn't even properly support this type of 'copy-and-modify' inheritance that Self and Javascript do. A save operation is required in between,
The "copy-and-modify" part of those languages isn't inheritance, it's construction: they don't have ordinary "constructors". They both support inheritance but they both don't use classes to do inheritance.
I don't beleive this is true of Javascript. The only way to "inherit" in javascript is to copy an existing object and then add methods to it from the object you want to inherit from.
No it's not: those languages have the "class" role played by ordinary objects: if you modify an object that is a "class" for other objects, those other objects immediately start behaving differently. That's even
I don't beleive this is true for Javascript either. Once you copy an object you get a totally new object - if you modify the original object you copied from, it will not affect the newly copied object, and if you modify the new object it will not affect the original object.
better than Pd because then, modifying code and applying changes doesn't need lose your settings: e.g. if [+ 42] is configured to add 37 instead, then changing the abstraction in a SELF-like way doesn't reset the changes.
If you ask me, this is more like having a fixed method of an object and giving it an argument that re-configures the way it works than modifying the code. But not entirely. This highlights the problem with trying to map concepts like "method" and "object" onto Pd.
I take your point though; "mostly dataflow but not completely unprocedural" sounds about right.
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Sun, 9 Apr 2006, Chris McCormick wrote:
On Fri, Apr 07, 2006 at 01:47:51PM -0400, Mathieu Bouchard wrote:
The "copy-and-modify" part of those languages isn't inheritance, it's construction: they don't have ordinary "constructors". They both support inheritance but they both don't use classes to do inheritance.
I don't beleive this is true of Javascript. The only way to "inherit" in javascript is to copy an existing object and then add methods to it from the object you want to inherit from.
No, you have to set a property called "prototype", to which property lookup of missing properties will be delegated. I don't know whether Javascript supports multiple prototypes, but the SELF language does. (SELF was a major inspiration for JavaScript)
No it's not: those languages have the "class" role played by ordinary objects: if you modify an object that is a "class" for other objects, those other objects immediately start behaving differently. That's even
I don't beleive this is true for Javascript either. Once you copy an object you get a totally new object - if you modify the original object you copied from, it will not affect the newly copied object, and if you modify the new object it will not affect the original object.
Once you copy an object you get a totally new object, but the "prototype" property is shared; i mean, it's a separate variable, but it points to the same object as the original "prototype" variable until you reassign it.
Here's a JavaScript tutorial that may help you understanding how prototypes work: http://www.codeproject.com/aspnet/JsOOP1.asp
If you ask me, this is more like having a fixed method of an object and giving it an argument that re-configures the way it works than modifying the code. But not entirely. This highlights the problem with trying to map concepts like "method" and "object" onto Pd.
I was talking about modifying the objects inside the abstraction. If you consider whatever you do in Edit Mode to be just "re-configuration", then you may as well call all code as "data" and coding as "re-configuring the compiler".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, Apr 13, 2006 at 02:17:54AM -0400, Mathieu Bouchard wrote:
On Sun, 9 Apr 2006, Chris McCormick wrote:
On Fri, Apr 07, 2006 at 01:47:51PM -0400, Mathieu Bouchard wrote:
The "copy-and-modify" part of those languages isn't inheritance, it's construction: they don't have ordinary "constructors". They both support inheritance but they both don't use classes to do inheritance.
I don't beleive this is true of Javascript. The only way to "inherit" in javascript is to copy an existing object and then add methods to it from the object you want to inherit from.
No, you have to set a property called "prototype", to which property lookup of missing properties will be delegated. I don't know whether Javascript supports multiple prototypes, but the SELF language does. (SELF was a major inspiration for JavaScript)
That is a cool feature; I did not know about the prototype property of objects in Javascript. Thanks for the heads up.
If you ask me, this is more like having a fixed method of an object and giving it an argument that re-configures the way it works than modifying the code. But not entirely. This highlights the problem with trying to map concepts like "method" and "object" onto Pd.
I was talking about modifying the objects inside the abstraction. If you consider whatever you do in Edit Mode to be just "re-configuration", then you may as well call all code as "data" and coding as "re-configuring the compiler".
Yes, point taken. But in my opinion, there isn't a one-to-one exact match between these concepts in programming and Pd patching. Patching is not programming. It's like programming. A number of features of 'patching' intersect with those of 'programming'.
In any case:
"Musicians have often used Max as a programming environment, at which Max succeeds only very awkwardly... This decision was made to remove a layer of complexity that didn't seem to be strictly necessary in the context of computer music production, in order to make Max as accessible as possible to people who aren't professional computer programmers... Rather than a programming environment, Max is fundamentally a system for scheduling real-time tasks and managing intercommunication between them."
-- MSP, http://crca.ucsd.edu/~msp/Publications/dartmouth-reprint.dir/
Maybe we should stop thinking "The diagram is the program. (TM)" and start thinking "The diagram is the audio/visual [real time] composition." instead. That is certainly closer to how I use Puredata.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Fri, 14 Apr 2006, Chris McCormick wrote:
Yes, point taken. But in my opinion, there isn't a one-to-one exact match between these concepts in programming and Pd patching. Patching is not programming. It's like programming. A number of features of 'patching' intersect with those of 'programming'.
What's the use of distinguishing 'patching' and 'programming' ?
Maybe we should stop thinking "The diagram is the program. (TM)" and start thinking "The diagram is the audio/visual [real time] composition." instead. That is certainly closer to how I use Puredata.
The reason why I started the "Diagram is the Program" campaign is because there isn't much of a difference between a contemporary interactive composition and a program. Making a distinction doesn't bring much good, and even if the distinction is kept, people will keep on trying to close the gap. That is happening even though many of those involved the gap don't believe that the gap ought to be closed!
I don't know why we should stop thinking "the diagram is the program" just to support the way you use PureData.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, Apr 15, 2006 at 01:44:50AM -0400, Mathieu Bouchard wrote:
On Fri, 14 Apr 2006, Chris McCormick wrote:
Yes, point taken. But in my opinion, there isn't a one-to-one exact match between these concepts in programming and Pd patching. Patching is not programming. It's like programming. A number of features of 'patching' intersect with those of 'programming'.
What's the use of distinguishing 'patching' and 'programming' ?
What's the use in ignoring the differences between 'patching' and 'programming'?
Maybe we should stop thinking "The diagram is the program. (TM)" and start thinking "The diagram is the audio/visual [real time] composition." instead. That is certainly closer to how I use Puredata.
The reason why I started the "Diagram is the Program" campaign is because there isn't much of a difference between a contemporary interactive composition and a program.
To some, contemporary interactive composition is a very different activity to programming. This is a personal and subjective thing to do with the way in which each person uses Pd, but for many people they are very different activities. You can not categorically make the statement that artistic patching is the exact same thing as computer programming.
Making a distinction doesn't bring much good, and even if the distinction is kept, people will keep on trying to close the gap. That is happening even though many of those involved the gap don't believe that the gap ought to be closed!
Sure, go ahead, close the gap. All the more interesting software for everyone. I will continue to use Pd as an artistic tool.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Sat, Apr 15, 2006 at 01:44:50AM -0400, Mathieu Bouchard wrote:
What's the use of distinguishing 'patching' and 'programming' ?
What's the use in ignoring the differences between 'patching' and 'programming'?
How about agreeing, that there *is* a difference between developing something through patching and developing something through writing text? While I do my fair share of programming with textual languages, I much prefer patching with Pd over writing structured texts when it comes to artistic work. I don't know why, I guess patching activates other switches and presses different buttons in my mind than writing does.
Ciao
On Sat, 15 Apr 2006, Frank Barknecht wrote:
Chris McCormick hat gesagt: // Chris McCormick wrote:
On Sat, Apr 15, 2006 at 01:44:50AM -0400, Mathieu Bouchard wrote:
What's the use of distinguishing 'patching' and 'programming' ?
What's the use in ignoring the differences between 'patching' and 'programming'?
How about agreeing, that there *is* a difference between developing something through patching and developing something through writing text?
I don't have a problem agreeing with it, if instead we call it "programming in pd" vs "programming in whatever else" respectively.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 15 Apr 2006, Chris McCormick wrote:
To some, contemporary interactive composition is a very different activity to programming. This is a personal and subjective thing to do with the way in which each person uses Pd, but for many people they are very different activities. You can not categorically make the statement that artistic patching is the exact same thing as computer programming.
It needs not to be considered mutually exclusive. Computer programming needs not to be the stereotypical computer programming.
Apart from saying that, I can't reply to you because your interactive composition is so personal and subjective that I can't know what it is except that it is "very different" and it's also "very different". So nevermind.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
(Part two)
On Fri, 7 Apr 2006, Chris McCormick wrote:
What is a method in Puredata?
It's something you hear about in PureData's error messages:
error: +: no method for 'symbol'
I think it's best not to try and cram OOP concepts into this perfectly good dataflow language.
haha, it's already full of OOP concepts.
Even putting PureData in the dataflow category is debatable, because there's too much dependency on execution order (not really because [t] exists, but because [t] has to be used so often!).
The way Pd handles execution order makes it part of a subset of dataflow languages that also handle execution order explicitly. If you think that execution order has to be handled in one certain way in all dataflow languages then your definition is more narrow than mine.
My definition of dataflow is rather wide, it's just that whoever does dataflow in a compsci department thinks that Pd is disguisedly procedural. Nevertheless when I started calling pd a "dataflow language", most nouns and adjectives used to describe pd were essentially the same as one would use to describe VisualBASIC. I thought that pd needed VERY MUCH to be distinguished from VisualBASIC so I recalled reading about the "dataflow paradigm" from a book by Raphael Finkel and thought that it was the most fitting. At about the same time I also renamed my IRC chat channel to #dataflow. (It's still active and has 26 pd users online right now)
But "paradigms" or language categories are a limited tool. If all languages fitted exactly in a category, then either every language would have its own category or most languages in a category would be equivalent. But, most of the time, the reason why we want a separate programming language is when it's *not* equivalent. There is conceptual innovation going on and a lot of it has to do with bending the categories.
I'd classify PureData as mostly dataflow but not completely unprocedural.
I would try and find something better (just incase Miller one day decides to crow-bar OO proper into Pd).
In Pd's internals, every t_method is associated to a t_class, and then every t_pd refers to a t_class. Every message gets sent to a t_pd. A t_pd doesn't have inlets. Inlets are icing on the cake and that's why the left inlet is so special when coding pd externals: when you talk to a left inlet you are talking directly to an object in OOP terms, but when you talk to a non-left inlet you go through a translator which turns a non-left-inlet message to a left-inlet message (or to some function-call related to the struct that has the left-inlet)
Pd doesn't have inheritance, but that doesn't prevent it from having a hierarchy: a [bng] button is a t_bng which is an extension of t_iemgui which is an extension of t_object which is an extension of t_gobj which is an extension of t_pd.
At the level of methods, inheritance wasn't implemented, so Thomas Musil hacked his own thingy so that he could reuse some code (but it's not a generic thing that can be transported outside of pd).
At the level of patching, inheritance can be partially replaced by deeply nested abstractions and a lot of [route]s, though those who'd like to implement mixins are screwed. How would you emulate virtual inheritance with abstractions and [route] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 7 Apr 2006, Mathieu Bouchard wrote:
At the level of methods, inheritance wasn't implemented, so Thomas Musil hacked his own thingy so that he could reuse some code (but it's not a generic thing that can be transported outside of pd).
DOH, errata:
generic thing that can be transported outside of iemgui, to be used by
pd classes in general).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Apr 7, 2006, at 10:49 PM, Mathieu Bouchard wrote:
On Fri, 7 Apr 2006, Mathieu Bouchard wrote:
At the level of methods, inheritance wasn't implemented, so Thomas Musil hacked his own thingy so that he could reuse some code (but it's not a generic thing that can be transported outside of pd).
DOH, errata:
generic thing that can be transported outside of iemgui, to be used by
pd classes in general).
The implementation is not the language. In the Pd language, there is no inheritance. The implementation could very well have inheritance. I believe that Thomas included some form of inheritance in flext, but that does not mean that Pd has inheritance.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
On Sat, 8 Apr 2006, Hans-Christoph Steiner wrote:
On Apr 7, 2006, at 10:49 PM, Mathieu Bouchard wrote:
generic thing that can be transported outside of iemgui, to be used by pd classes in general).
The implementation is not the language. In the Pd language, there is no inheritance. The implementation could very well have inheritance. I believe that Thomas included some form of inheritance in flext,
The presence of inheritance (and substitutes for inheritance) in the implementation of the language suggests that there should be inheritance in the language itself.
Thanks for restating what I was already saying in the mail you were replying to:
On Apr 7, 2006, at 10:49 PM, Mathieu Bouchard wrote:
Pd doesn't have inheritance, but
Now why are you trying to explain to me that Pd doesn't have inheritance???
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
At the level of patching, inheritance can be partially replaced by deeply nested abstractions and a lot of [route]s, though those who'd like to implement mixins are screwed. How would you emulate virtual inheritance with abstractions and [route] ?
inside a patch needing a few additional methods (assuming it has a single inlet), i'd just wire in any number of abstractions in series. inside those abstractions would be a route, for the methods which the mixin abstractions implement.. i havent actually tried this. im fairly sure i would consider my OSC/message recording things a mixin as well, simply create one in a subpatch, and you have a local send/recieve variable which can forward arbitrary messages to the global 'recording agent'..similar to AOP logging..
in any case there are definitely OO concepts at play, in a world where structs-within-structs or creative $0 tricks are as close as one can currently go.
Hans, if youre stilll reading, how does 'meta' sound? i do like the idea of collecting all these dynamic patching things in one place..
C
On Apr 8, 2006, at 12:12 AM, carmen wrote:
At the level of patching, inheritance can be partially replaced by deeply nested abstractions and a lot of [route]s, though those who'd like to implement mixins are screwed. How would you emulate virtual inheritance with abstractions and [route] ?
inside a patch needing a few additional methods (assuming it has a single inlet), i'd just wire in any number of abstractions in series. inside those abstractions would be a route, for the methods which the mixin abstractions implement.. i havent actually tried this. im fairly sure i would consider my OSC/message recording things a mixin as well, simply create one in a subpatch, and you have a local send/recieve variable which can forward arbitrary messages to the global 'recording agent'..similar to AOP logging..
in any case there are definitely OO concepts at play, in a world where structs-within-structs or creative $0 tricks are as close as one can currently go.
Hans, if youre stilll reading, how does 'meta' sound? i do like the idea of collecting all these dynamic patching things in one place..
Part of PDDP is standard meta information, so a "meta" lib should probably handle that stuff. I still think that "object" in the context of Pd makes good sense since it's a collection of objects used for writing objects.
(I deliberatly say "object" and not "class", since "class" implies a lot of OOP concepts which are not in Pd, like subclass/superclass, class tree/hierarchy, inheritance, etc.).
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On Sat, 8 Apr 2006, Hans-Christoph Steiner wrote:
(I deliberatly say "object" and not "class", since "class" implies a lot of OOP concepts which are not in Pd, like subclass/superclass, class tree/hierarchy, inheritance, etc.).
that sounds like three times the same concept, isn't it? that's a lot.
Pd's got patchcords, wires and connections... and lines too. straight lines. that's a lot too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 8 Apr 2006, carmen wrote:
inside a patch needing a few additional methods (assuming it has a single inlet), i'd just wire in any number of abstractions in series.
You mean in series or nested?
inside those abstractions would be a route, for the methods which the mixin abstractions implement..
and it's even possible to make messages be both processed and continue to a nested abstraction. however, what is very much unlike OOP inheritance about it, is that the $0 is different. It's also possible to do the same message-forwarding tricks in most OOP languages (except C++ and some others) but still a lot of things get done using one instance using of several.
one place where the nested abstractions (or series of abstractions) approach loses is in cases where an object is sending messages to itself, as a matter of efficient internal organisation (especially useful in abstract classes). In a system in which messages don't have return-values, it's damn difficult to use such a feature anyway, but there would be something feasible about it, if $0 were the same in the "subinstance" (which corresponds to a superclass: sub because it's inside, super because it represents something more general.)
Mixin inheritance (as it is in Ruby, Strongtalk, CLOS or Self) is currently unimplementable in PureData, because you can't automatically eliminate duplicate "subinstances".
im fairly sure i would consider my OSC/message recording things a mixin as well, simply create one in a subpatch, and you have a local send/recieve variable which can forward arbitrary messages to the global 'recording agent'..similar to AOP logging..
er, I'm not sure what this has to do with AOP and not with just a global variable. Where exactly does an object gets automatically wrapped? The way I can explain it, in OOP a subclass wraps a superclass, but in AOP, you can also have a superclass wrap a subclass, and even both at the same time, and also unrelated superclasses can wrap each other if they meet in a certain subclass, and I mean all automatical wrappers that you never need to explicitly specify. (i'm just thinking of CLOS method lookup, haven't tried other AOP systems)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 7 Apr 2006, carmen wrote:
Would you like to elaborate on that?
i'd just rather not see a bunch of workaround hacks packaged with the 'object' prefix, i think it should be reserved for something builtin. for an example of this, see Ruby's "Object" object.. diagram of the day: http://rhg.rubyforge.org/images/ch_object_classtree.png
this one is cool too:
http://rhg.rubyforge.org/images/ch_class_simulate.png
i find this one funnier though:
http://rhg.rubyforge.org/images/ch_class_mmm.png
obviously, the "mmm" in the filename stands for metametameta.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 7 Apr 2006, at 04:13, carmen wrote:
Would you like to elaborate on that?
i'd just rather not see a bunch of workaround hacks packaged with the 'object' prefix, i think it should be reserved for something builtin. for an example of this, see Ruby's "Object" object..
Not that I can call myself an expert in OO, but I have to say PD is just dataflow, nothing OO about it, so the keyword object being reserved is pre-empting something irrelevant IMO.
d
-
carmen -
Chris McCormick -
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard