Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

From: Mark S. Hathaway (hathawa2_at_marshall.edu)
Date: 07/14/04 

Date: Wed, 14 Jul 2004 14:37:10 -0400

>> "Mark S. Hathaway" <hathawa2@marshall.edu> wrote in
>> news:40f3c7d0@alpha.wvnet.edu:
>>
>> That one would "know" an object is a number and not a string
>> clarifies what I've said about the type of a thing being too
>> dynamic for any static system to completely cover. You accept
>> that and say that coercion is sufficient for the exceptional
>> instances.

> Cristiano Sadun wrote:
>
> Hei Mark,
>
> it's sufficient when the number of occurrences in your control flows when
> the type needs to be translated is small. Otherwise, one creates a
> specific type which makes the translation unnecessary (a bad situation is
> when the same entity is used in n different ways in more or less 100/n %
> of the cases.. then one faces a design dilemma).
>
> Let's say I intially think 'x' is an integer number. Then, while coding,
> I realize that I'm actually using it as a String 80% of the times
> (something that, with a minimum analysis, shouldn't even happen too
> much); or that I actually need something more structured (be a struct or
> a class). Well, I refactor the code to use String or the struct/class.
>
> All it's left then is the 20% of the cases - when I'll have to translate
> to the original int.
>
> Note that I don't claim that the 20% wouldn't be perhaps saved by full
> DT. 'course it would. I just say that - to me - it's a cost acceptably
> small. In almost 15 years of software development with a bunch of
> languags, I'd had to do such things many times (and generally with far
> less sophisticated tools than today), and I never felt that *that* was a
> main factor for less-than-expected productivity of a major source of
> hassle. Of course my perception could be unobjective.

I know that what you're describing is an extreme, perhaps even
rare case, so I won't pick at that. However, the very idea that
you might have to re-identify an object is disconcerting.

> Cristiano Sadun wrote:
>
> From my point of view, the presence of exceptional instances
> which turn to be not so exceptional (i.e. case 2) just leads to inventing
> *the possibility of creating your own types* (as opposed to having to
> build everything with predefined ones); be them object oriented (i.e.
> classes) or not (for example, pascal-like TYPE definitions). I see this
> as orthogonal to OO.

That certainly explains why that kind of language feature
was created.

> OO is about packaging data and operations (aka behaviour) together.
> Static typing is about telling the system about our intentions - which of
> course requires both the possibility of knowing them and actually
> exercising that possibility.

I think OO is about divide-and-conquer modularization and
of making a completely consistent language system where
creation of types and their use is everything. Fewer different
language features, but the right ones.

Why should you have to tell the "system" your intentions twice?
Isn't the usage of objects already an exposition of your intentions?

>> Mark wrote:
>>
>> That 2) may be 100% completely correct doesen't dissuade many
>> people from wanting to handle those fringe instances with more
>> formality, control, precision, etc.

> Cristiano Sadun wrote:
>
> To what are you referring here? DT, leaving type mismatch checking
> completely at runtime, seems to me having *less* formality and precision
> - or better, leaves lots of formality and precision to run-time, which is
> exactly part of my point.

Take for example the way Smalltalk handles Numbers. An Integer
isn't 'coerced' into a String or Float, it's handled smoothly
by the language system. There's less progrmmer intervention
with homemade code which muddies up the primary algorithm.

That goes to the point I made in another post about the type
system of older static type languages being a little incomplete
and requiring programmers to write their own code, here and
there, to make sure things like '1/0' are handled properly.
It's messy, redundant, perhaps more likely to fail and it
hides the primary algorithm.

>> Mark wrote:
>>
>> Odd as it may seem, it's the dropping of static type systems
>> and embracing OOPL class libraries with inheritance that they
>> believe gives them more flexibility.

> Cristiano Sadun wrote:
>
> Wait a sec, I don't get it. OOPL class libraries with inheritance are a
> specific mechanism to create types. That's completely another matter to
> having these types checked statically (at compile time) or dinamycally
> (entirely at runtime). You can have static/dynamic type systems both for
> OO and not-OO types.

     static type checking <--> dynamic
classes with inheritance <--> no inheritance

What I'm thinking is that those who prefer dynamic type
checking also would prefer a class library system with
inheritance because those both lend themselves to more
flexibility (freedom to create their own new types/classes),
less redundancy in the creation of types/classes and
less clutter in the final program text.

That static type checking and a class library system
with inheritance can exist isn't impossible, just odd.

>>they can reuse the word "Push" or the character symbol "*"
>>and they don't worry about whether the underlying meaning
>>of that symbol is consistent, so long as it's use in the
>>context of a particular class is correct.
>>
>>Push the bulldog!

> So long it doesn't bite.. :)

Alright! Now we're making progress.

>>If only one particular meaning is accepted for a symbol,
>>then why have modules or classes, just have one global
>>namespace.

> Oh, but for a bunch of other reasons: managing complexity, that's just
> the first that pops in mind.

Yes, that's what pure OOPLs do too.

More progress!

Relevant Pages

  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... That certainly explains why that kind of language feature ... >> and embracing OOPL class libraries with inheritance that they ...
    (comp.programming)
  • Re: A taxonomy of types
    ... (I do not see why inheritance is required here.) ... without an »object-oriented programming language«, for example, ... in the programming language used. ... indirectly) implements an interface IA whose declaration ...
    (comp.lang.misc)
  • Re: Redefine Normal style
    ... The only reasons to use it are: ... chain of inheritance to Normal (which is a good thing: ... Language: US English. ... Normal + Language: US English, ...
    (microsoft.public.mac.office.word)
  • Re: Terminology: Inheritance through a component
    ... If you want data inheritance you must support it, ... > and containing an object of the base class is one way of doing that. ... LSP is supported in your language. ... These kinds of phrases are familiar to anyone using the automation products ...
    (comp.object)
  • Re: [Info-ingres] Re: What animal should Ingres be?
    ... > parts, such as they are, are the class libraries - and I presume that any ... > a byte code interpreted procedural language, I vote for p-code Pascal;) ... I vote for TOOL: all the power of Java, plus transactions, ...
    (comp.databases.ingres)