Marius and I are sitting here arguing over whether we should use the
term "class" or "object" in the pdpedia as the standard term for
differentiation, e.g. bang (class) vs. bang (selector).
I think the current usage of the term "object" in Pd has two
meanings: an instance of a class, and the class itself. I think we
should distinguish between these two in the pd wiki, and the word
"class" is quite well established for that.
Yes, that means some education for some users, but that's a big part
of the pdpedia mission.
That's my take, Marius will now disagree. :D
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
as hans already knew, I disagree. I have not heard the term class before. I think the term class is really not in use by pd users. what you (hans) call a class is called an object by everybody else... [class] <-- that is not a class, it is an object. [message( <-- and that is a message. when we are talking about "dac~", then we are talking about the object dac~, even if it is not the technically correct term (I learned now: it is a class, until you make an instance of the class, that is called object) but that is confusing. please use object!
marius.
Hans-Christoph Steiner wrote:
Marius and I are sitting here arguing over whether we should use the term "class" or "object" in the pdpedia as the standard term for differentiation, e.g. bang (class) vs. bang (selector).
I think the current usage of the term "object" in Pd has two meanings: an instance of a class, and the class itself. I think we should distinguish between these two in the pd wiki, and the word "class" is quite well established for that.
Yes, that means some education for some users, but that's a big part of the pdpedia mission.
That's my take, Marius will now disagree. :D
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
it took me 5 months to figure out the difference between objects, externals, and abstractions....god only knows how much longer it would have taken if i'd had to deal with 'classes' as well. i probably would have given up.
'object' has always been used (even if it is sometimes incorrectly used)..and i personnally wouldn't recommend changing that.
On Thu, 13 Sep 2007, hard off wrote:
it took me 5 months to figure out the difference between objects, externals, and abstractions....god only knows how much longer it would have taken if i'd had to deal with 'classes' as well. i probably would have given up. 'object' has always been used (even if it is sometimes incorrectly used)..and i personnally wouldn't recommend changing that.
If it took you 5 months to figure it out, it's because that information is too hard to get and people didn't push it to you either. If I teach pd, then on the first day, or even the first hour, I get people to know: classes, objects, messages, methods. I could perhaps skip on methods but then how do you get people to make sense of "no method for...".
I personally can't recommend sticking with calling a class "an object", because it puts pd at odds with the terminology of almost every object-oriented programming language in use today.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
how about naming the 'class' 'objectclass' instead?
although you are probably right, marius, that most of the pd users do not know the term 'class', they'd probably understand 'objectclass'.
On Wed, 2007-09-12 at 15:07 -0400, marius schebella wrote:
as hans already knew, I disagree. I have not heard the term class before. I think the term class is really not in use by pd users. what you (hans) call a class is called an object by everybody else...
certainly not true, marius. i know some people who are using 'class' instead of 'object'. also i would prefer 'class', though i am not quite sure right now, what to use, that is why i sometimes use 'object'. and for consistency's sake: why not introducing something new to get more clearness and to avoid confusion beforehand? at least in my opinion the differentiation between a [dac~] and the 'dac~' in general is quite important.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Wed, 2007-09-12 at 22:13 +0200, Steffen wrote:
On 12/09/2007, at 21.47, Roman Haefeli wrote:
at least in my opinion the differentiation between a [dac~] and the 'dac~' in general is quite important.
I would love some insight on that. If you or anyone would care to elaborate?
sorry, the [dac~] vs. 'dac~ in general' wasn't a good example at all.
actually it is pretty simple. what i meant here was the distinction between the class 'dac~' and the object 'dac~'. the object 'dac~' is an intantiation of the class 'dac~', whereas the class 'dac~' is what you would describe in pdpedia.
the term 'class' somehow covers all capabilities, that 'dac~' does provide you. you can decide to make use of these capabilities by creating an object [dac~ 2 4], which is another object than [dac~ 1 3] (or even another object than another [dac~ 2 4]).
actually, you never see a class, you just know, that it exists, but you probably see many [objects] of this class.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On 12/09/2007, at 22.41, Roman Haefeli wrote:
On Wed, 2007-09-12 at 22:13 +0200, Steffen wrote:
On 12/09/2007, at 21.47, Roman Haefeli wrote:
at least in my opinion the differentiation between a [dac~] and the 'dac~' in general is quite important.
I would love some insight on that. If you or anyone would care to elaborate?
sorry, the [dac~] vs. 'dac~ in general' wasn't a good example at all.
actually it is pretty simple. what i meant here was the distinction between the class 'dac~' and the object 'dac~'. the object 'dac~'
is an intantiation of the class 'dac~', whereas the class 'dac~' is what you would describe in pdpedia.the term 'class' somehow covers all capabilities, that 'dac~' does provide you. you can decide to make use of these capabilities by creating an object [dac~ 2 4], which is another object than [dac~ 1 3] (or even another object than another [dac~ 2 4]).
actually, you never see a class, you just know, that it exists, but
you probably see many [objects] of this class.
Wauw. I don't know how this explanation would work on a complete
newbee, but to me it was both very concise and pedagogical. Thanks.
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.
Roman Haefeli wrote:
On Wed, 2007-09-12 at 22:13 +0200, Steffen wrote:
On 12/09/2007, at 21.47, Roman Haefeli wrote:
at least in my opinion the differentiation between a [dac~] and the 'dac~' in general is quite important.
I would love some insight on that. If you or anyone would care to elaborate?
sorry, the [dac~] vs. 'dac~ in general' wasn't a good example at all.
actually it is pretty simple. what i meant here was the distinction between the class 'dac~' and the object 'dac~'. the object 'dac~' is an intantiation of the class 'dac~', whereas the class 'dac~' is what you would describe in pdpedia.
the term 'class' somehow covers all capabilities, that 'dac~' does provide you. you can decide to make use of these capabilities by creating an object [dac~ 2 4], which is another object than [dac~ 1 3] (or even another object than another [dac~ 2 4]).
actually, you never see a class, you just know, that it exists, but you probably see many [objects] of this class.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2007-09-12 at 17:22 -0400, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.
i don't know what to say, you are so right..... :-)
it's true that - regarding pd - i didn't find the term class anywhere. nevertheless, i personally wouldn't be against the introduction of the term 'class' at all, since it describes what it is anyway. no matter what convention is currently used, when we are talking about 'dac~' we are talking about the class 'dac~', even if the convention says, that we should call it 'object'. i vote for turning the facts into conventions rather than sticking with conventions, which are wrong.
although i absolutely see your point: one vote -> class (or objectclass)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hmmmm... hmmmmm... will you be the one to ask miller to change his documentation? marius.
Roman Haefeli wrote:
On Wed, 2007-09-12 at 17:22 -0400, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.
i don't know what to say, you are so right..... :-)
it's true that - regarding pd - i didn't find the term class anywhere. nevertheless, i personally wouldn't be against the introduction of the term 'class' at all, since it describes what it is anyway. no matter what convention is currently used, when we are talking about 'dac~' we are talking about the class 'dac~', even if the convention says, that we should call it 'object'. i vote for turning the facts into conventions rather than sticking with conventions, which are wrong.
although i absolutely see your point: one vote -> class (or objectclass)
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Wed, 2007-09-12 at 17:49 -0400, marius schebella wrote:
hmmmm... hmmmmm... will you be the one to ask miller to change his documentation? marius.
good point.....
now, i really don't know what to say....
roman
Roman Haefeli wrote:
On Wed, 2007-09-12 at 17:22 -0400, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.
i don't know what to say, you are so right..... :-)
it's true that - regarding pd - i didn't find the term class anywhere. nevertheless, i personally wouldn't be against the introduction of the term 'class' at all, since it describes what it is anyway. no matter what convention is currently used, when we are talking about 'dac~' we are talking about the class 'dac~', even if the convention says, that we should call it 'object'. i vote for turning the facts into conventions rather than sticking with conventions, which are wrong.
although i absolutely see your point: one vote -> class (or objectclass)
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hey all,
my vote is for object, although it's technically incorrect.
Thinking of my course next semester, i guess i would have a hard time
explaining the class/object difference to the students, most of who
have no programming experience at all.
I tend to think that for pd this differentiation is not really an
issue outside external programming (which isn't targetted in this
discussion).
gr~~~
Am 12.09.2007 um 23:41 schrieb Roman Haefeli:
On Wed, 2007-09-12 at 17:22 -0400, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object
oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd
documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.i don't know what to say, you are so right..... :-)
it's true that - regarding pd - i didn't find the term class anywhere. nevertheless, i personally wouldn't be against the introduction of
the term 'class' at all, since it describes what it is anyway. no matter what convention is currently used, when we are talking about 'dac~' we are talking about the class 'dac~', even if the convention says,
that we should call it 'object'. i vote for turning the facts into conventions rather than sticking with conventions, which are wrong.although i absolutely see your point: one vote -> class (or objectclass)
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is a ton of documentation out there, and there are varying
standards about how things are described and named. We can't heed
them all, so we should come up with something that is clean and concise.
The term "class" has not really been used in Pd land much at all.
The term "object" has been used for both classes and instances. I
think that Roman's suggestion is a good one. "objectclass" should be
clear in Pd space, yet makes the important distinction between
"class" and "instance".
One example of why this is relevant in Pd land is when you create
your own classes in Pd. If you create a patch, save it as a file,
then load it into another patch, then you have created a class, and
instances of that class.
I vote for clearer documentation and terminology over keeping old bad
habits. :D
.hc
On Sep 12, 2007, at 5:59 PM, Thomas Grill wrote:
Hey all, my vote is for object, although it's technically incorrect. Thinking of my course next semester, i guess i would have a hard time explaining the class/object difference to the students, most of who have no programming experience at all. I tend to think that for pd this differentiation is not really an issue outside external programming (which isn't targetted in this discussion).
gr~~~
Am 12.09.2007 um 23:41 schrieb Roman Haefeli:
On Wed, 2007-09-12 at 17:22 -0400, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object". marius.
i don't know what to say, you are so right..... :-)
it's true that - regarding pd - i didn't find the term class
anywhere. nevertheless, i personally wouldn't be against the introduction of the term 'class' at all, since it describes what it is anyway. no matter what convention is currently used, when we are talking about
'dac~' we are talking about the class 'dac~', even if the convention says, that we should call it 'object'. i vote for turning the facts into
conventions rather than sticking with conventions, which are wrong.although i absolutely see your point: one vote -> class (or objectclass)
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
On 13/09/2007, at 5.11, Hans-Christoph Steiner wrote:
The term "class" has not really been used in Pd land much at all. The term "object" has been used for both classes and instances
Just to clarify. Abstractions are classes too? Such that an instance
of and abstraction is called an object?
(I never really got tired of functional programming, so pardon my
ignorance.)
On Thu, 13 Sep 2007, Steffen wrote:
On 13/09/2007, at 5.11, Hans-Christoph Steiner wrote:
The term "class" has not really been used in Pd land much at all. The term "object" has been used for both classes and instances
Just to clarify. Abstractions are classes too? Such that an instance of an abstraction is called an object?
Yes. An abstraction file is a class; a loaded abstraction is an object.
(I never really got tired of functional programming, so pardon my ignorance.)
Most likely you mean procedural programming, but it doesn't help that several of the most common language of that kind (C/C++/etc) calls its procedures "functions".
Many people still call that "structured programming" instead but i believe that this way of calling it is historical and buzzword-driven. I think of "structured programming" as something that encompasses almost all of programming nowadays including object-oriented programming. In that sense, object-oriented programming is an extension of procedural programming. Some languages (C++) make that extension optional while some others express everything in terms of that extension.
Some call object-oriented programming "a radical paradigm shift"... it may be for someone who has a narrow view of programming, but when the paradigm is like "solve your problem using anything that the language offers, whichever way that is most direct", then those new (40 year old) tools called "objects" "methods" "classes" will look more approachable than if you rely on a methodology that always supposes that procedures are the best tool for anything.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
The term "class" has not really been used in Pd land much at all. The term "object" has been used for both classes and instances
Just to clarify. Abstractions are classes too? Such that an instance of an abstraction is called an object?
Well...everything in PD is an abject if it is saved as an abstraction, or an external. Perhaps the distinction between abstractions and externals is quite relevant, since one is coded in PD and the other in C, C++, Python, Ruby etc. One requires PD, the other requires compilation, paths etc. If we are going to make an accessible form of documentation for PD then surely it makes sense to start from the outside - where most people approaching PD will begin. Within PD, the boundaries between object and abstraction are deliberately blurred - which is useful for programmers. Outside, it is not obvious which is which. Distinguishing between the two - and defining them - is important for newcomers to the project.
The biggest problem I had when approaching PD for the first time, as an artist knowing nothing about C etc, was getting externs I wanted to use working (in 2000 with RedHat 5.2)
Matju, I'm already in love with your cat, but I am unfortunately allergic to cats and will therefore weep at the sight of it.
Best, Ed
Lone Shark "Aviation" out now on http://www.pyramidtransmissions.com http://www.myspace.com/sharktracks
For ideas on reducing your carbon footprint visit Yahoo! For Good this month.
On Wed, 12 Sep 2007, Thomas Grill wrote:
my vote is for object, although it's technically incorrect. Thinking of my course next semester, i guess i would have a hard time explaining the class/object difference to the students, most of who have no programming experience at all.
It's a concept that they already know since they are very little. Many nouns refer to something that there can be many instances of and of which the noun acts as a class. Thus saying "the cat" refers to an individual, "the cats" refers to several individuals, "cats" (alone) refers to cats in general (class), and so does "all cats" and in another way "any cat" also does.
There must be a way to leverage that kind of intuition or knowledge.
I tend to think that for pd this differentiation is not really an issue outside external programming (which isn't targetted in this discussion).
do you teach abstractions? how do you do that without saying "class"? probably using a word that stands for "class".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Am 13.09.2007 um 09:06 schrieb Mathieu Bouchard:
It's a concept that they already know since they are very little.
Many nouns refer to something that there can be many instances of
and of which the noun acts as a class. Thus saying "the cat" refers
to an individual, "the cats" refers to several individuals,
"cats" (alone) refers to cats in general (class), and so does "all
cats" and in another way "any cat" also does.
Hmmm, i can follow your reasing, but i guess noone would say "class
of cats" when he/she means cats in general. That would be "objects"
for pd then, not "class".
There must be a way to leverage that kind of intuition or knowledge.
I tend to think that for pd this differentiation is not really an
issue outside external programming (which isn't targetted in this
discussion).do you teach abstractions? how do you do that without saying
"class"? probably using a word that stands for "class".
For abstractions, the word is "abstraction". An abstraction in turn
contains objects that may be of type "message", "sub patch",
"abstraction" or "external/binary object".
I always use "external object" to mean an object that can't be opened
as a patch. That worked quite well so far, although i'm interested in
more correct formulations without complicating things.
gr~~~
Thomas Grill wrote:
For abstractions, the word is "abstraction". An abstraction in turn contains objects that may be of type "message", "sub patch", "abstraction" or "external/binary object". I always use "external object" to mean an object that can't be opened as a patch.
for pdpedia I would like to have the same page layout for external objects and abstractions. I am talking about standardized abstractions like the pdmtl abstractions. I refer to the pd fileformat, that lists abstractions as "obj". I therefore tend to call abstraction also "objects". a message in my opinion is no object. I think also a sub patch is not a real object, although it is created in an object box. (if you open the pd file with a text editor, you will not find the word "obj", it is a canvas, which is also not an object for me, I am not sure about atomboxes (numbers and symbols). but also arrays and comments are no objects in that sense. otherwise, please can someone find a meta term for "everything that can be created inside an objectbox (ctrl-1)". marius.
Hi Marius,
what i wrote in the last mail is my personal usage of notions up till
now (because i was asked). I don't think that it's the way to go.
The meta term for me is "object", as said before.
gr~~~
Am 13.09.2007 um 16:51 schrieb marius schebella:
Thomas Grill wrote:
For abstractions, the word is "abstraction". An abstraction in
turn contains objects that may be of type "message", "sub patch",
"abstraction" or "external/binary object". I always use "external object" to mean an object that can't be
opened as a patch.for pdpedia I would like to have the same page layout for external
objects and abstractions. I am talking about standardized
abstractions like the pdmtl abstractions. I refer to the pd
fileformat, that lists abstractions as "obj". I therefore tend to
call abstraction also "objects". a message in my opinion is no object. I think also a sub patch is
not a real object, although it is created in an object box. (if you
open the pd file with a text editor, you will not find the word
"obj", it is a canvas, which is also not an object for me, I am not
sure about atomboxes (numbers and symbols). but also arrays and
comments are no objects in that sense. otherwise, please can someone find a meta term for "everything that
can be created inside an objectbox (ctrl-1)". marius.
On Thu, 13 Sep 2007, Thomas Grill wrote:
Hmmm, i can follow your reasing, but i guess noone would say "class of cats" when he/she means cats in general. That would be "objects" for pd then, not "class".
They wouldn't think of a cat as an object and they wouldn't say a "cat object" either, so, one way or another, you are teaching them to use a certain word.
For abstractions, the word is "abstraction". An abstraction in turn contains objects that may be of type
But you don't distinguish the abstraction instances from the original one that the user made?
That worked quite well so far, although i'm interested in more correct formulations without complicating things.
Incorrect or vague formulations are an excellent way to complicate things. Don't look at just the cost of using precise formulations, look also at the cost of using vague ones.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
my vote is for object, although it's technically incorrect. Thinking of my course next semester, i guess i would have a hard time
explaining the class/object difference to the students, most of who
have no programming experience at all. I tend to think that for pd this differentiation is not really an
issue outside external programming (which isn't targetted in this
discussion).
This is a "me too"-message from me: For the same reasons as Thomas I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.
It occured to me that it may sound like I'd try to "dumb down" Pd for artists, which is not my intention, so I'd like to clarify a bit:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an object of the class.
So in the pdpedia context using the term "object" for the list of building blocks in my view wouldn't be wrong at all. As "object" also is the term that is generally used when talking about Pd patches here--as in: "Just put an [osc~] object into your patch to make a sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank, it's my turn now to absolutely second what you said.
gr~~~
Am 13.09.2007 um 15:32 schrieb Frank Barknecht:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas
I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.It occured to me that it may sound like I'd try to "dumb down" Pd for artists, which is not my intention, so I'd like to clarify a bit:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an object of the class.
So in the pdpedia context using the term "object" for the list of building blocks in my view wouldn't be wrong at all. As "object" also is the term that is generally used when talking about Pd patches here--as in: "Just put an [osc~] object into your patch to make a sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
as much as i like matjus cat example and i can't help thinking of his
white fat shy beast roaming around his computers i have to “third”
franks point.
Am 13.09.2007 um 10:29 schrieb Thomas Grill:
Hi Frank, it's my turn now to absolutely second what you said.
gr~~~
Am 13.09.2007 um 15:32 schrieb Frank Barknecht:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas I'd prefer to stick with "object". While "class" is more correct, I
think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.It occured to me that it may sound like I'd try to "dumb down" Pd for artists, which is not my intention, so I'd like to clarify a bit:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an
object of the class.So in the pdpedia context using the term "object" for the list of building blocks in my view wouldn't be wrong at all. As "object" also is the term that is generally used when talking about Pd patches here--as in: "Just put an [osc~] object into your patch to make a
sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Thu, 13 Sep 2007, Max Neupert wrote:
as much as i like matjus cat example and i can't help thinking of his white fat shy beast roaming around his computers
If you actually held that cat in your hands you'd know that the cat is not fat. Most of her volume is hair and air between the hair. She's not quite white either. Quite a few people on pd-list could testify ;)
i have to ?third? franks point.
You still have time to change your mind...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Thu, 13 Sep 2007, Max Neupert wrote:
as much as i like matjus cat example and i can't help thinking of his white fat shy beast roaming around his computers
If you actually held that cat in your hands you'd know that the cat is not fat. Most of her volume is hair and air between the hair. She's not quite white either. Quite a few people on pd-list could testify ;)
Yes, she(?) felt quite non-solid and soft.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, Sep 13, 2007 at 03:32:39PM +0200, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.
It occured to me that it may sound like I'd try to "dumb down" Pd for artists, which is not my intention, so I'd like to clarify a bit:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an object of the class.
So in the pdpedia context using the term "object" for the list of building blocks in my view wouldn't be wrong at all. As "object" also is the term that is generally used when talking about Pd patches here--as in: "Just put an [osc~] object into your patch to make a sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.
Once again Frank provides the concise voice of reason! I agree with 100% with this in the case of pdpedia and most every day usages. However I see nothing wrong with establishing a rule of thumb for educators and other people describing pd, to follow when they do definately want to describe the "class of objects" of type [osc~] not just to say "put an [osc~] object into your patch" but for something more complicated, and call this the "object class" like Matju says. For example if someone is explaining about what externals are. That is a good and every-day intuitive use of the word "class" for normal people as well as being acceptable to us abnormal computer scientists (as Matju pointed out already).
Best,
Chris.
On Thu, 13 Sep 2007, Chris McCormick wrote:
For example if someone is explaining about what externals are. That is a good and every-day intuitive use of the word "class" for normal people as well as being acceptable to us abnormal computer scientists (as Matju pointed out already).
I wouldn't quite describe myself as a computer scientist. I'm nowadays somewhat at odds with the computer scientist mentality. Neither could you really say that I'm not an artist: even though I only work on other people's projects, I still end up making artistic decisions.
Pd tends to attract people from the artist-programmer continuum. I don't think that it's useful to rely on stereotyping those people into two opposing clusters... People in the middle of the spectrum shouldn't have to decide whether they're an artist or a programmer.
When teaching pd, a more important "fault line" when trying to compartmentalise information and vocabulary, is whether a concept or word is of exclusive usefulness to a certain activity (e.g. such as programming C externals). If you teach how to patch, you don't want to teach proxy-inlets vs float-inlets, because they don't appear at all at the level of patching; likewise, if you teach how to write C externals, you don't want to be explaining t_bindlist because that concept is only useful in the internals of pd. (well, actually, some externals *could* mess with that, but you're not supposed to). However, distinctions between t_pd, t_gobj, t_scalar and t_object can be useful in explaining the big picture of how pd works, because each of them corresponds to a specific concept that you encounter in pd as "just a user". Some kinds of implementation-hiding are pointless...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 13 Sep 2007, Frank Barknecht wrote:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an object of the class.
No, you can also query the class for a helpfile. When doing that in pd, it's expressed as a synecdoche: you ask the object for the helpfile but in reality pd figures it out from the class. It is perfectly correct to say that helpfiles are class-specific: they cannot be set in a finer-grained way. Then in turn what a helpfile documents happens to be a class too: it documents all possible objects of that class at once.
The object is the unit of patching, but the class is the unit of understanding.
here--as in: "Just put an [osc~] object into your patch to make a sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.
If you decide to use the word "class", you don't have to be saying "class" everywhere where a class is involved. You don't have to pick between plugging the word "class" as often as possible or hide it all of the time. "Just put an [osc~] object" already implies the longer form. It's a pattern already encoded in the grammatical structure of English and other natural languages. In this case, [osc~] acts as an adjective and represents a class rather than a particular object. Contrast this to saying just "an [osc~]", in which it's a noun representing an object. In saying "all [osc~] are..." it's a noun representing all possible objects, and that actually is talking about the class because the class is all its own possible objects. There's nothing wrong with saying things in those ways and use the word "class" whenever it's actually warranted.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Sep 13, 2007, at 9:32 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas
I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists. I'd say,, reserve the term class for pd-dev.It occured to me that it may sound like I'd try to "dumb down" Pd for artists, which is not my intention, so I'd like to clarify a bit:
We're talking about what term to use in pdpedia for the descriptions of the available building blocks for patches, mainly externals and abstractions. When building patches, what users (scientists and artists) deal with, are objects. The only thing you can do with a class when building a patch is to make an instance of it: an object of the class.
So in the pdpedia context using the term "object" for the list of building blocks in my view wouldn't be wrong at all. As "object" also is the term that is generally used when talking about Pd patches here--as in: "Just put an [osc~] object into your patch to make a sine wave." Nobody says: "Instantiate the [osc~] class to make a sine wave."--it is perfectly valid to use "object/symbol" on pdpedia. IMO at least.
I am still up in the air about this. While many Pd programmers
rarely write their own object classes (abstractions, externals...), I
think this is not something that should be encouraged. I think we
should be encouraging people to learn about writing their own object
classes, by writing better docs, and improving Pd, and spreading the
knowledge.
Part of writing better docs is coming up with clear and concise
terminology. There is an important distinction that should be made
much clearer than it currently is. "class" is a term that is rarely
used in Pd land, we don't have to use that term. But I think that we
should make a point to make the issues clear, rather than just saying
"most people will probably never use that idea anyway, and few people
ever talk about it in detail, and everyone just says it like this now
anyhow."
On that note, I have yet to hear a term that I think really is the
right one. But I do think that "objectclass" is a workable
compromise for Pdpedia. And if no one ever uses the word
"objectclass" outside of Pdpedia, I think that is also fine. How
often do you use the word "disambiguation" or "selector"?
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Thu, 13 Sep 2007, Frank Barknecht wrote:
This is a "me too"-message from me: For the same reasons as Thomas I'd prefer to stick with "object". While "class" is more correct, I think the difference is something only computer scientists are interested in
Until they use abstractions with sends/receives and they hit the problem that they want to separate one instance from another. Then you have to teach $0 and you have to teach the difference.
and Pd has a tradition of not always following the path of mainstream computer science anyway, because it's not a tool mainly targetting computer scientists but one targetting artists.
and so what? it's still programming. It's still targeted at people who do programming by their very act of using pd. A programmer is someone who programs.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
marius schebella wrote:
what you say make sense, it is just not true for Pd.
Look at m_pd.h, you will find "class" written a lot. In fact the most important function for writing externals is called "class_new".
I vote for removing the confusion that exists currently, by using the word "class" when you mean "kind of object" and "object" when you mean "instance of object". To continue the current situation where you don't know if object means class or if object means instance would be foolish.
Claude
On Wed, 12 Sep 2007, marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects".
It's a synecdoche. The part (an object) is the sign, but the signified is the whole (the class). Thus "the [+] object" means "a [+] object" or rather "any [+] object".
'"reference" patches, one for each kind of object in Pd'. so even if there is the technical differentiation between that not instantiated thing, usually called "class" and the instance of it, called "object", that naming convention is not true for Pd. both, the "class" and the instance are known as "object".
Or sometimes "class" is known as "kind of object", as you have yourself quoted.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
marius schebella wrote:
what you say make sense, it is just not true for Pd. in object oriented programming (and maybe other programming too) the instantiation of a "class" is called object. but referring to the miller's pd documentation (html) there are no classes, and he calls classes "objects". '"reference" patches, one for each kind of object in Pd'.
stupid me, be here he speaks about "king of object" which (for me) describes an abstraction (not in the .pd sense) of the actual "object". there is a name for this platonic ideal of "object": "class"
apart from that, i do not see a necessity to use either of these terms. why can't we just use "/bang" for the class (or however you want to call it).
if someone sees the urge for having selectors in the wiki (which i don't, but that is just me), this one could be called "bang_(selector)" and i am not so sure whether we need a disambiguation page for the both, and if we do, why not call it "bang_(disambiguation)"?
mfa.r IOhannes
On Thu, 13 Sep 2007, IOhannes m zmoelnig wrote:
apart from that, i do not see a necessity to use either of these terms. why can't we just use "/bang" for the class (or however you want to call it).
Because if classes have that kind of precedence, and you have a page on a certain concept which happens later to have a class by the same name, you don't want to have to move that content to another page just so that the class gets the main entry.
if someone sees the urge for having selectors in the wiki (which i don't, but that is just me),
How do you want to document things across classes? Because always documenting things class-by-class removes some of the big picture. Perhaps they should be documented in a page called "/object" which would contain everything common to all t_objects, for example. Most classes don't define a method for every one of the built-in selectors, but some aspects of those methods/selectors are still defined at that level rather than in the class that defines the method.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 12 Sep 2007, Roman Haefeli wrote:
how about naming the 'class' 'objectclass' instead? although you are probably right, marius, that most of the pd users do not know the term 'class', they'd probably understand 'objectclass'.
I often write "object class" in the context of pd precisely because the pd documentation eschews the "class" word and that almost every teacher does the same. Everybody else in almost any OO programming language knows what "class" means.
Just be careful not to say "class object", which is a different concept. pd doesn't have those, but it could. This is an object representing a class. It could also be called "object class object".
differentiation between a [dac~] and the 'dac~' in general is quite important.
There are further distinctions between the class vs the class name, the class vs the creator, and the creator vs the creator name... If you want, I could show you. In practice, "class" is not really the thing that matters from a user's point of view; the "creator name" is the only thing actually seen... but almost all of the time, you can avoid making the difference. Those further distinctions are not as useful as class-vs-object.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Chris McCormick -
Claude Heiland-Allen -
Ed Kelly -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
marius schebella -
Mathieu Bouchard -
Max Neupert -
Roman Haefeli -
Steffen -
Thomas Grill