Hi!
My 2 eurocents:

> Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

This paragraph is what explain it all:
"The day when a programming language needs to accommodate the machine rather
than the human has long since passed. Indeed, in Microsoft's Visual
Studio .NET suite of languages, the compiled result is identical whether
you use Java, C++, or Basic. But professionals and academics haven't heard
this news, or they're just dismissing it. They continue to favor C++ and
other offspring of C."

Well, he says OOP is bad, unless is Microsoft flavoured... A bit
unconsistent:)))

Byez!!
Carotinho

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csqfoa$28u9$1@digitaldaemon.com...
> Walter wrote:
> > "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csphdp$1872$1@digitaldaemon.com...
> >
> >>Should Phobos be procedural? Should it be entirely converted to
> >>OOP? Should there be (an arbitrary level) beyond which we switch to OOP?
> >>Or should there be certain parts where OOP is used and others where it
> >>really should be avoided? Or entirely two alternate versions of Phobos?
>
> >For each particular problem, use whatever fits the best.
>
> I guess we all do that. And I think we should. But my fear above was that if "whatever fits the best [right here]" is used in standard library development, the result might be inconsistent, and hard to use because there is no "easy to remember logic" or pattern.
>
> (I'm actually only talking about the API. The internals may of course be programmed with "whatever fits the best [right here]".)

I understand your point, but I don't think that forcing something into OOP when it doesn't belong makes it easier to use.

"John Reimer" <brk_6502@yahoo.com> wrote in message news:csr0cs$2uap$1@digitaldaemon.com...
> PS.  The note about windows slowing down: you've noticed that too?  I'm glad I'm not the only one!  And I thought I had power to spare...

It comes from all the crapola that applications software loads into the startup list. For example, I have an HP film scanner. It loads some program into the startup list that always runs. I have no idea what it does. I have no idea why anything from the HP scanner software needs to run unless I actually try to use the scanner.

Digital Mars software, on the other hand, doesn't load until you actually try to use it. Then, when you're done, it unloads. Uninstalling it is as simple as blowing away the directory it sits in. It can be run off of the CD without even installing it. You can transfer it to your new machine when upgrading by xcopying the directory. What a concept!

"Walter" <newshound@digitalmars.com> wrote in message news:cssh2o$1mrp$1@digitaldaemon.com...
>
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csqfoa$28u9$1@digitaldaemon.com...
>> Walter wrote:
>> > "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csphdp$1872$1@digitaldaemon.com...
>> >
>> >>Should Phobos be procedural? Should it be entirely converted to
>> >>OOP? Should there be (an arbitrary level) beyond which we switch to OOP?
>> >>Or should there be certain parts where OOP is used and others where it
>> >>really should be avoided? Or entirely two alternate versions of Phobos?
>>
>> >For each particular problem, use whatever fits the best.
>>
>> I guess we all do that. And I think we should. But my fear above was that if "whatever fits the best [right here]" is used in standard library development, the result might be inconsistent, and hard to use because there is no "easy to remember logic" or pattern.
>>
>> (I'm actually only talking about the API. The internals may of course be programmed with "whatever fits the best [right here]".)
>
> I understand your point, but I don't think that forcing something into OOP when it doesn't belong makes it easier to use.

Agreed. I think the principle that the 'lower' level of procedural should always be preferred to the 'higher' level of OO, in the same way that one should always prefer a simpler API/design/methodology over a more complicated, except where the more complicated one is warranted. KISS, in other words.

"Walter" <newshound@digitalmars.com> wrote in message news:csshkk$1nge$1@digitaldaemon.com...
>
> "John Reimer" <brk_6502@yahoo.com> wrote in message news:csr0cs$2uap$1@digitaldaemon.com...
>> PS.  The note about windows slowing down: you've noticed that too?  I'm glad I'm not the only one!  And I thought I had power to spare...
>
> It comes from all the crapola that applications software loads into the startup list. For example, I have an HP film scanner. It loads some program into the startup list that always runs. I have no idea what it does. I have no idea why anything from the HP scanner software needs to run unless I actually try to use the scanner.
>
> Digital Mars software, on the other hand, doesn't load until you actually try to use it. Then, when you're done, it unloads. Uninstalling it is as simple as blowing away the directory it sits in. It can be run off of the CD without even installing it. You can transfer it to your new machine when upgrading by xcopying the directory. What a concept!

And DMC++ has influenced me to the degree that all software I write now, including that for clients, attempts to do the same, except where that is not feasible.

The long hand of Mr Bright carries onward ...

In article <cssi06$1nmp$1@digitaldaemon.com>, Matthew says...
>
>Agreed. I think the principle that the 'lower' level of procedural should always be preferred to the 'higher' level of OO, in the same way that one should always prefer a simpler API/design/methodology over a more complicated, except where the more complicated one is warranted. KISS, in other words.
>

Plus that still makes it easily possible to have an OOP interface for OO enthusiasts (or applications where its just easier/better to use) by writing a wrapper class/collection.

-- Chris Sauls

In article <cssjiv$1pk1$1@digitaldaemon.com>, Chris Sauls says...
>
>In article <cssi06$1nmp$1@digitaldaemon.com>, Matthew says...
>>
>>Agreed. I think the principle that the 'lower' level of procedural should always be preferred to the 'higher' level of OO, in the same way that one should always prefer a simpler API/design/methodology over a more complicated, except where the more complicated one is warranted. KISS, in other words.
>>
>
>Plus that still makes it easily possible to have an OOP interface for OO enthusiasts (or applications where its just easier/better to use) by writing a wrapper class/collection.
>
>-- Chris Sauls

It depends somewhat upon where that KISS is directed.

FWIW I'd have to agree with all this except that, in many cases, the extra OO steps one has to take (when designing a set of classes) results in a cleaner outcome: easier to use, maintain, and live with.

There's a lot of KISS there :-)

One can, of course, take that approach with procedural code also. Hands up how many actually go to that trouble?

(my hand is half up ...)

Unfortunately, there are many examples of procedural code that is simply slapped together, like some of those "anti-fashion award" recipients.

Such examples are often hard to use, have little or no cohesion (or cognitive trails), expose overlap in functionality, asymmetric features, and exhibit brittle behaviour. Extending such a beast typically introduces yet more warts. The primary issue there is usually a lack of project management, forethought and/or design refactoring.

One of those examples is a lot closer to going public than we should allow it to be ...

Naturally, one can thoroughly bork an OO implementation also. Just as naturally, no-one should use such an animal, either; let alone be "encouraged" to use it.

- Kris

"Chris Sauls" <Chris_member@pathlink.com> wrote in message news:cssjiv$1pk1$1@digitaldaemon.com...
> In article <cssi06$1nmp$1@digitaldaemon.com>, Matthew says...
>>
>>Agreed. I think the principle that the 'lower' level of procedural should always be preferred to the 'higher' level of
>>OO, in the same way that one should always prefer a simpler API/design/methodology over a more complicated, except
>>where
>>the more complicated one is warranted. KISS, in other words.
>>
>
> Plus that still makes it easily possible to have an OOP interface for OO enthusiasts (or applications where its just easier/better to use) by writing a wrapper class/collection.

Absolutely!

"Kris" <Kris_member@pathlink.com> wrote in message news:csslse$1s4q$1@digitaldaemon.com...
> In article <cssjiv$1pk1$1@digitaldaemon.com>, Chris Sauls says...
>>
>>In article <cssi06$1nmp$1@digitaldaemon.com>, Matthew says...
>>>
>>>Agreed. I think the principle that the 'lower' level of procedural should always be preferred to the 'higher' level
>>>of
>>>OO, in the same way that one should always prefer a simpler API/design/methodology over a more complicated, except
>>>where
>>>the more complicated one is warranted. KISS, in other words.
>>>
>>
>>Plus that still makes it easily possible to have an OOP interface for OO enthusiasts (or applications where its just easier/better to use) by writing a wrapper class/collection.
>>
>>-- Chris Sauls
>
> It depends somewhat upon where that KISS is directed.
>
> FWIW I'd have to agree with all this except that, in many cases, the extra OO steps one has to take (when designing a set of classes) results in a cleaner outcome: easier to use, maintain, and live with.
>
> There's a lot of KISS there :-)
>
> One can, of course, take that approach with procedural code also. Hands up how many actually go to that trouble?
>
> (my hand is half up ...)
>
> Unfortunately, there are many examples of procedural code that is simply slapped together, like some of those "anti-fashion award" recipients.
>
> Such examples are often hard to use, have little or no cohesion (or cognitive trails), expose overlap in functionality, asymmetric features, and exhibit brittle behaviour. Extending such a beast typically introduces yet more warts. The primary issue there is usually a lack of project management, forethought and/or design refactoring.
>
> One of those examples is a lot closer to going public than we should allow it to be ...
>
> Naturally, one can thoroughly bork an OO implementation also. Just as naturally, no-one should use such an animal, either; let alone be "encouraged" to use it.

If you're alluding to certain elements of undue coupling in Phobos, then I concur. ;)

Walter wrote:
> "John Reimer" <brk_6502@yahoo.com> wrote in message
> news:csr0cs$2uap$1@digitaldaemon.com...
> 
>>PS.  The note about windows slowing down: you've noticed that too?  I'm
>>glad I'm not the only one!  And I thought I had power to spare...
> 
> 
> It comes from all the crapola that applications software loads into the
> startup list. For example, I have an HP film scanner. It loads some program
> into the startup list that always runs. I have no idea what it does. I have
> no idea why anything from the HP scanner software needs to run unless I
> actually try to use the scanner.
> 
> Digital Mars software, on the other hand, doesn't load until you actually
> try to use it. Then, when you're done, it unloads. Uninstalling it is as
> simple as blowing away the directory it sits in. It can be run off of the CD
> without even installing it. You can transfer it to your new machine when
> upgrading by xcopying the directory. What a concept!
> 
> 

I must admit, I've really come to appreciate the simple way digitalmars deals with installation.  I wish all software installation were that simple.

- John