Re: OO's best feature survey results

From: Topmind (topmind_at_technologist.com)
Date: 11/01/03 

Date: 1 Nov 2003 00:59:12 -0800

>
> > > You always need the boolean type.
> > >
> > > if a = '1' then
> > > ...
> >
> > That could simply be a short-cut for:
> >
> > if isEqual(a, '1') then ....
>
> Again isEqual returns a boolean value.

You are correct in that "if" needs to know
what to react to and what not to react to.
However, in some languages even IF is a
function or object or closure which could
be user-defined. Someone could say, "I will
make IF proceed if the values (strings) are
such and such and not proceed otherwise
(jump over)."

I would probably define a boolean "string"
as a string that is either blank, zero,
or has a first letter that is "f" or
"n" for "false" or "no"

>
> > Again, assume that "+" is just a shortcut for an
> > Add() function. For the sake of argument, assume
> > that Add is not a built-in function.
> >
> > c = add(a, b)
> >
> > >
> > > This language is still typed, but I would like to detect the error in
> > > compilation time.
> >
> > What Add() or isEqual() does is up to the implementor(s).
>
> Then you can not detect many errors at compile time.
>
> I don't know anybody except you that would like to use a language like
> that.

I LIKE dynamic languages. I learned mostly on typed languages,
but over the years I have grown to prefer dynam because
they do more with less code, making it easier to
read and visually inspect. They also make it
easier to use meta data or tables to define stuff. This is
not the place to debate static typing versus dynamic
typing. It is an age-old debate that never ends, and
appears to be a personal preference. There are ways
to flag "suspicious" parts of dynamic code, BTW.

>
> It is harder to use and error prone without any gain. It is a
> regression to assembler.

Like I said, dynamic languages have less formality and
less "clutter" IMO.

>
> > > > "Type"
> > > > is something very temporial in this approach.
> > >
> > > No, types are immutable and eternal, but variables may hold values of
> > > many types.
> >
> > Didn't Universe just say that types are, or are often situational?
> > You two should get on the same page, or perhaps agree that
> > "type" is a psychological viewpoint and not a universal
> > truth.
>
> Type is a math concept. Types are independent to time.

So you have a mathematical test that could take say
a set of classes from any OO language and tell if
they are or share the same type?

>
> > > How do you solve this?
> > >
> > > if '10' > '9' then ...
> >
> > See above.
>
> I have not seen the solution.
>
> You can't know if I want to make a string or a numerical comparisson.

I prefer languages that have a different operator for numerical
comparison than for string comparison. Perl is an example of
such (although I would do it syntactically different
if given a choice).

>
> > "Types" are too artificial IMO for many things, perhaps most.
>
> There is nothing wrong in being artificial.

To a point. I don't find the philosophy of types
very useful. They don't map to my head, and you seem
to agree that they don't map to the real world
that well. So, what is left? Mapping to YOUR head?
Perhaps, but it ain't my head.

>
> > > > Besides, typing working on a small scale does not necessarily
> > > > translate to a larger scale. Extrapolating "integer" ADT
> > > > type concepts to business entities is a big leap.
> > >
> > > Business entities map very well to relation typed variables (AKA
> > > tables).
> >
> > I don't know that entity == type. If so, why have a separate
> > term "entity"?
>
> entity == type is a great blunder. But it is a very common blunder in
> the OO world.
>
> BTW type is a formal term while entity is not.

I am skeptical of this claim.

>
> > > Without types the relational model can not exist.
> >
> > I disagree. True, the "Oracle way" and its clones may involve typed
> > columns, but I don't see anywhere where relational theory
> > demands types anymore than a procedural language does.
>
> Relational theory demands at least boolean types, tuple types and
> relation types.

I think you are overusing "type". Boolean is an interface,
not a type.

>
> Without types you don't have tables, you only have mem cells.
>
> > Why not call them constraints instead of types?
>
> Among other things because constraints don't have operations.
>
> How do you represent a table with a string?

Tables can be represented many different ways.
Convert them to XML if you want to see strings.

>
> > Constraints can be mixed and matched also so that
> > they do not always form a clean tree. In otherwords,
> > a "set of constraints".
>
> Type hierarchies are not always trees.
>
> > This is turning into a definition issue. I don't question
> > that everything can be viewed as types IF one wants to,
>
> The type concept is precise. In a programming language a type can be
> viewed as a set of values and a set of operators that act over that
> values.

Sounds more like set theory than "type". This differs too much
from the "street meaning" of types.

>
>
> Regards
> Alfredo

-T-