Re: c.d.theory glossary -- definition of "class"

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 24 Jun 2004 21:42:21 +0200
Message-ID: <40db2ea6$0$36860$e4fe514c_at_news.xs4all.nl>


Alfredo Novoa wrote:

>>>Behavior is a very informal and fuzzy term. The behavior is determined
>>>by the semantics of the operators. This is a term we should drop in
>>>formal contexts.
>>

> mAsterdam wrote:
>>Complex, yes. Dynamic, yes. Fuzzy, no.

>
> Complex, yes. Simple, yes. Dynamic, yes. Static, yes. Fuzzy, yes :)
>
>>Fuzzy here is the blurring of semantics and pragmatics.
>>The behavior is determined by the *use* (as opposed to *meaning*)

>
> No, the behavior IS the manner in which something functions or
> operates.

I could go with that.
Rather subtle difference.
Appearently not *that* fuzzy.

> "Manner" and "something" are also fuzzy terms.

If you look closer at anything it becomes fuzzy. Zoom in more and you will only see parts of it, not the whole anymore.
Zoom out and you will see it in it's context. Zoom out more and it dissappears.

> Types imply some behavior, although they are constant, variables imply
> some behavior, integrity constraints imply some behavior, derivation
> rules imply some behavior, operators imply some behavior, etc.
>
> There is database behavior, application behavior, presentation
> behavior, user's behavior, good behavior, bad behavior and many other
> behaviors.
>
> I don't see any usefulness in the term having a lot more precise terms
> like:

What makes them more precise?

> type, variable, value and operator. Probably the four key terms in
> computer language theory.

I would not know. They are important allright. So are operand, expression, flow, grammar, execution, control, key(word), declaration, assignment, token, symbol, ( and ). But I did not do a count of them.
What makes these four special?

>>>Yes if we have alternatives with only one meaning.
>>
>>Not if these disregard valuable notions.

>
> What valuable notions "class" and "behavior" have that we can not find
> in the more precise terms?

Your question is distracting.
http://www.datanation.com/fallacies/distract/cq.htm Not agreeing with you about the precision makes it harder to answer your question. I take it you mean type, variable, value and operator.

Type, variable, value all have static connotations. operator in combination with variable introduces some dynamics. In short you lose the essence of OO.

>>>We should help to reduce the number :)
>>
>>Of people using databases?  ;-)

>
> Of people confused due to the use of imprecise words.

I would not like to see them replaced by even more people who can't describe what they see for lack of words.

>>Well, yes. But IMHO there is an essential, (dynamic) notion
>>getting lost if we use 'type' as a would-be synonym.

>
> Can you clarify this?

Probably not to your satisfaction, I am affraid. I'll give it a try anyway.

I first read about 'actor languages' in the late seventies in a magazine called Creative computing. These later came to fame as 'object oriented'. This amounted to a (little) degradation of the dynamic aspects - actors are active by definition, object may be passive. 'type' as used in "Compilers. Principles, techniques, and tools by Aho, Sethi and Ullman, is a property of an operand (so passive to the operator).

In the terms I see a chain from active to passive. Actor - object (class) - type.

term : applies to : context : characterised by :

-------|---------------|----------|------------------|
type   : operand       : static   : a set of values
class : communicator : dynamic : behavior

The dynamic/static connotation is valuable IMO.

> When class means type it means type and nothing more.

Indeed. Not very useful, and not how the terms are used.

> Types have operators, and operators act on values, thus they have
> behavior :)

Types are associated with operators in their role as operand. They have behavior in a puppet-like way.

> BTW "have" is an extremely ambiguous word :-)

No problem. I rephrased.

> We don't need any extension. Types have operators.

And so many people agree with you on that. What is your problem if types don't *have* but are *subjected-to* operators? Received on Thu Jun 24 2004 - 21:42:21 CEST

Original text of this message