www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there a lower level to OOP?

reply Georg Wrede <georg.wrede nospam.org> writes:
Some programming languages or paradigms are consistent (read: 
monotheistic) from the bottom (grass roots level, near the metal) to the 
top (main level of application). (e.g. Forth, Lisp, OOP in Java) 
Actually, in the old days, most of them were.

But today, when we are wiser, is such fervor fruitful? This might sound 
as an utterly academic question, but what happens if we are designing a 
library? 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?

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.
Jan 20 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:csphdp$1872$1 digitaldaemon.com...

 But today, when we are wiser, is such fervor fruitful? This might sound
 as an utterly academic question, but what happens if we are designing a
 library? 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?

 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.


Certainly OOP has been oversold in the past. It's not the solution to every
programming problem. But it is still a convenient paradigm for a lot of
common problems. D supports OOP well, but it also supports procedural and
metaprogramming paradigms. For each particular problem, use whatever fits
the best.
Jan 20 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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]".)
Jan 21 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jan 21 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Jan 21 2005
parent reply Chris Sauls <Chris_member pathlink.com> writes:
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
Jan 21 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
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
Jan 21 2005
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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. ;)
Jan 21 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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!
Jan 21 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <csphdp$1872$1 digitaldaemon.com>, Georg Wrede says...

(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.


Forgive me, but (IMO) that article is one amusing exercise in FUD :-)

Anyone who claims that OOP is somehow directly tied to a "paradigm shift from
DOS to Windows", or that C++ is "not as difficult" as C, is seriously misguiding
their readers ... 

The title is "Think object-orient programming (OOP) is the only way to go? You
poor, misguided soul." 

So who in their right mind would claim that any one strategy is the /only/ way
to go? 

Perhaps the title should have been "I think machine-language is the only way to
go; just look at my book titles; and then buy 'em all"

I agree, George, that there's a slight tinge of reality to some of the notions.
But that's the basis of FUD; you've got to make part of it sound vaguely
familiar before dragging the reader along to Mr Toad's vaccuum booth. 

There a place and a time for OOP, just as there is for any other development
style. I imagine that sorry author already knows this, yet deliberately wrote
some "controversial" nonsense just to plug himself, again.

- Kris
Jan 20 2005
parent reply parabolis <parabolis softhome.net> writes:
Kris wrote:

 In article <csphdp$1872$1 digitaldaemon.com>, Georg Wrede says...
 

(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.


 
 
 Forgive me, but (IMO) that article is one amusing exercise in FUD :-)


 From the "Typing Monkey" manual: "...If the final text is incoherent 
babbling please throw it away and wait for a better one. Your typing 
monkey is guaranteed to eventually write something pertinent..."
Jan 20 2005
parent Dave <Dave_member pathlink.com> writes:
In article <cspqai$1hpk$1 digitaldaemon.com>, parabolis says...

Kris wrote:

 
 Forgive me, but (IMO) that article is one amusing exercise in FUD :-)


 From the "Typing Monkey" manual: "...If the final text is incoherent 
babbling please throw it away and wait for a better one. Your typing 
monkey is guaranteed to eventually write something pertinent..."


http://www.newtechusa.com/ppi/main.asp
Jan 20 2005
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Qu'un nit-wit. N'est pas?

As Kris says, a few dissembling correct points, intermixed in with total drek:

 "The day when a programming language needs to accommodate the machine rather
than the human has long since passed". - 
can someone explain to me how, in the past six months of Windows Update my 2GHz
/ 512MB machine has gone from a 
lightning quick box to something that regularly takes 10s of seconds to go
between large applications? "long since 
passed" my arse.

 "Programmers describe it as little Ashley's first birthday party: the computer
starts counting from zero, so to the 
machine it's her zeroth birthday party." - pathetic

 "So colleges now turn out thousands of programmers annually who don't even
know that serious alternatives to C++ or OOP 
exist." - do they? Maybe where the author lives. Any contact I've had with
Unis, or their products, in the last half 
decade have revealed a disconcerting bias towards that obfuscator of
understanding: Java.

 "OOP apologists keep making the same excuses over and over: you don't
understand OOP yet (it takes years of practice; 
you can't simply read about it in a book); your company isn't correctly
implementing OOP" - as a search through the 
history on this ng will attest, I am absolutely *not* a fan of pure OO, but
this guy's just talking total kack, or he 
associates only with morons. Most of my clients are quite adept at OO. Not
perfect perhaps, but not in the least 
reminiscent of these dubiously real people to which the author alludes. Drek.
Drek. Drek

 "I find that leaving the data in a database and the data processing in the
application simplifies my programming. 
Leaving data separate from processing certainly makes program maintenance
easier, particularly when the overall 
structure of the data changes, as is so often the case in businesses (the most
successful of which continually adapt to 
changing conditions). OOP asks you to build a hierarchical structure and
thereafter try to adapt protean reality to that 
structure." - disingenuous drek!

"Computer "science" is littered with the debris of abandoned ideas." - yeah,
and the sky is blue and 10% of all people 
asked in a questionnaire whether they like cabbage will respond that they have
no idea where the nearest police station 
is.

 "Encapsulation, too, is a noble goal in theory: you've reached the Platonic
ideal for a particular programming job, so 
you seal it off from any further modification. And to be honest, constructing a
class often is fun. It's like building a 
factory that will endlessly turn out robots that efficiently do their jobs, if
you get all the details right. You get to 
play mad scientist, which can be challenging and stimulating. The catch is that
in the real world programming jobs 
rarely are perfect, nor class details flawless." - Please, please, please!!! If
there be a programming god, please let 
me live out my years never coming into contact with any technical system that
this author has even walked past. 
Encapsulation is not a mechanism for specification of "the perfect class", it
is about enforcement of design.

At this point, i.e. on that last point, I must desist, lest I vomit on the
floor. This author has, methinks, lost 
credibility for all time, due to his obvious, yet incomprehensible, inability
to comprehend some of the basic tenets of 
design, coding, refactoring, all of which are basic skills for people in our
industry. 32 books, eh? He'll not be short 
of doorstops, then.

Drek!


"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:csphdp$1872$1 digitaldaemon.com...

 Some programming languages or paradigms are consistent (read: monotheistic)
from the bottom (grass roots level, near 
 the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in
Java) Actually, in the old days, most of 
 them were.

 But today, when we are wiser, is such fervor fruitful? This might sound as an
utterly academic question, but what 
 happens if we are designing a library? 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?

 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.
Jan 21 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Wow, I think we have missed you Matthew!

:-D

- John R.

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...

Matthew wrote:

 Qu'un nit-wit. N'est pas?
 
 As Kris says, a few dissembling correct points, intermixed in with total drek:
 
  "The day when a programming language needs to accommodate the machine rather
than the human has long since passed". - 
 can someone explain to me how, in the past six months of Windows Update my
2GHz / 512MB machine has gone from a 
 lightning quick box to something that regularly takes 10s of seconds to go
between large applications? "long since 
 passed" my arse.
 
  "Programmers describe it as little Ashley's first birthday party: the
computer starts counting from zero, so to the 
 machine it's her zeroth birthday party." - pathetic
 
  "So colleges now turn out thousands of programmers annually who don't even
know that serious alternatives to C++ or OOP 
 exist." - do they? Maybe where the author lives. Any contact I've had with
Unis, or their products, in the last half 
 decade have revealed a disconcerting bias towards that obfuscator of
understanding: Java.
 
  "OOP apologists keep making the same excuses over and over: you don't
understand OOP yet (it takes years of practice; 
 you can't simply read about it in a book); your company isn't correctly
implementing OOP" - as a search through the 
 history on this ng will attest, I am absolutely *not* a fan of pure OO, but
this guy's just talking total kack, or he 
 associates only with morons. Most of my clients are quite adept at OO. Not
perfect perhaps, but not in the least 
 reminiscent of these dubiously real people to which the author alludes. Drek.
Drek. Drek
 
  "I find that leaving the data in a database and the data processing in the
application simplifies my programming. 
 Leaving data separate from processing certainly makes program maintenance
easier, particularly when the overall 
 structure of the data changes, as is so often the case in businesses (the most
successful of which continually adapt to 
 changing conditions). OOP asks you to build a hierarchical structure and
thereafter try to adapt protean reality to that 
 structure." - disingenuous drek!
 
 "Computer "science" is littered with the debris of abandoned ideas." - yeah,
and the sky is blue and 10% of all people 
 asked in a questionnaire whether they like cabbage will respond that they have
no idea where the nearest police station 
 is.
 
  "Encapsulation, too, is a noble goal in theory: you've reached the Platonic
ideal for a particular programming job, so 
 you seal it off from any further modification. And to be honest, constructing
a class often is fun. It's like building a 
 factory that will endlessly turn out robots that efficiently do their jobs, if
you get all the details right. You get to 
 play mad scientist, which can be challenging and stimulating. The catch is
that in the real world programming jobs 
 rarely are perfect, nor class details flawless." - Please, please, please!!!
If there be a programming god, please let 
 me live out my years never coming into contact with any technical system that
this author has even walked past. 
 Encapsulation is not a mechanism for specification of "the perfect class", it
is about enforcement of design.
 
 At this point, i.e. on that last point, I must desist, lest I vomit on the
floor. This author has, methinks, lost 
 credibility for all time, due to his obvious, yet incomprehensible, inability
to comprehend some of the basic tenets of 
 design, coding, refactoring, all of which are basic skills for people in our
industry. 32 books, eh? He'll not be short 
 of doorstops, then.
 
 Drek!
 
 
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
news:csphdp$1872$1 digitaldaemon.com...
 

Some programming languages or paradigms are consistent (read: monotheistic)
from the bottom (grass roots level, near 
the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in
Java) Actually, in the old days, most of 
them were.

But today, when we are wiser, is such fervor fruitful? This might sound as an
utterly academic question, but what 
happens if we are designing a library? 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?

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.
Jan 21 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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!
Jan 21 2005
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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 ...
Jan 21 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
Jan 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 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.


While there are advantages of using a single directory,
I prefer using a package manager myself. (such as RPM)

It makes the compilation and setup easier, while still
allowing for that single command uninstall / upgrade...

When installing on Linux from a tarball/zipfile, I must:
1) unzip 2) edit confs 3) copy to /usr *or* edit $PATHs

With a package, I can just use a single command or double-click?
I also get all the dependencies and requirements, automatically.


With regular applications (not compilers), I also like drag and drop.
Use it all the time on the Mac OS X, when packages are not required ?

--anders

PS. http://www.algonet.se/~afb/d/dmd-0.111-3.nosrc.rpm
     http://www.digitalmars.com/d/archives/digitalmars/D/13575.html
Jan 22 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Björklund wrote:


 
 While there are advantages of using a single directory,
 I prefer using a package manager myself. (such as RPM)
 
 It makes the compilation and setup easier, while still
 allowing for that single command uninstall / upgrade...
 
 When installing on Linux from a tarball/zipfile, I must:
 1) unzip 2) edit confs 3) copy to /usr *or* edit $PATHs
 
 With a package, I can just use a single command or double-click?
 I also get all the dependencies and requirements, automatically.
 
 
 With regular applications (not compilers), I also like drag and drop.
 Use it all the time on the Mac OS X, when packages are not required ?
 
 --anders
 
 PS. http://www.algonet.se/~afb/d/dmd-0.111-3.nosrc.rpm
     http://www.digitalmars.com/d/archives/digitalmars/D/13575.html



Hello Anders,

Linux and Mac OS are a completely different matter.  In those cases, I 
agree with you: the package system makes things a whole lot easier.

In my previous post, I was referring to the installation proccess of 
applications on Windows machines only.  I've come to appreciate simple 
install methods, as demonstrated by Walter's software, over messy 
registry based ones.  Installing any other way creates a clogged, messy 
Windows machine.

- John R.
Jan 22 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:


 In my previous post, I was referring to the installation proccess of 
 applications on Windows machines only.  I've come to appreciate simple 
 install methods, as demonstrated by Walter's software, over messy 
 registry based ones.  Installing any other way creates a clogged, messy 
 Windows machine.


In my encounters with Windows machines, it was usually something like:
start InstallShield exe, Next, Next, Next, Next, Next, Finish. (Reboot?)

Uninstalling was something like Add/Remove Programs, Hope For The Best ?
(you still had to format and reinstall everything every 6 months anyway)

Didn't look back. ;-)
--anders

PS. Apple's Installer doesn't even *have* an uninstall option, sadly.
     While it's the "easiest" option, I think RPM/Fink do it better...
Jan 22 2005
prev sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
John Reimer wrote:

 Linux and Mac OS are a completely different matter.  In those cases, I
 agree with you: the package system makes things a whole lot easier.


It's not only the package system, but also the question of "who packs up the
program". On Windows, everybody packs up their own programs into
installers. Of course the original author of a program often thinks: "Hey
this program is so important - everybody would want it to be started right
after boot-up. Uninstalling? Of course, I'll be polite and implement this,
but why would anybody want use that feature anyway?"

On Linux, packaging is usually done by a distributor who usually has a
slighly more realistic view about the importance of programs.
Jan 23 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 But today, when we are wiser, is such fervor fruitful? This might sound 
 as an utterly academic question, but what happens if we are designing a 
 library? Should Phobos be procedural? Should it be entirely converted to 
 OOP? Should there be (an arbitrary level) beyond which we switch to OOP? 


Phobos *is* procedural. Some people hate this (hello, Ant! :-))
See for instance http://dool.sourceforge.net/manifestDool.html

You can follow the war under the "should there be a String class",
along with some heated discussion if arrays and dictionaries belong
in the core language or should be implemented as Collection classes...
To me, C and Java represents the "extremes". D is somewhere in-between.


The direction taken so far seems to be that runtime library provides
basic classes and then a function/struct based runtime API. And that
any implementation of an object-oriented API is left as an exercise ?

One very nice such "exercise" completed, is Kris's The Mango Tree:
http://svn.dsource.org/svn/projects/mango/trunk/doc/html/index.html
It has a lot of real-life implementations, and also Log4J and ICU!

--anders
Jan 21 2005
prev sibling next sibling parent Paul Bonser <misterpib gmail.com> writes:
Georg Wrede wrote:

 
 Some programming languages or paradigms are consistent (read: 
 monotheistic) from the bottom (grass roots level, near the metal) to the 
 top (main level of application). (e.g. Forth, Lisp, OOP in Java) 
 Actually, in the old days, most of them were.
 
 But today, when we are wiser, is such fervor fruitful? This might sound 
 as an utterly academic question, but what happens if we are designing a 
 library? 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?
 
 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.


Sooo, yeah, there's so much wrong with that article that it makes me 
angry, and then sick, and then angry again, and then confused.

What's all this nonsense about "hiding code"...both from others and from 
yourself...
When you're working on a project with others, it's not like they just 
give you an object code version of their work, you build the whole thing 
yourself, meaning you have full access (to read if it's someone else's, 
to modify any way you like if it's yours) to all the source code. How is 
changing a couple things in a class any different from changing a 
function and some data in a non-OOP design.

You can re-write a class, increase its efficiency and whatnot, and it 
can still have the same interface, so you aren't kept from ever touching 
it again, as he seems to imply.

My guess is that he's scared that he's losing too much market for books 
on machine language to higher-level languages. Sure OOP isn't good for 
everything, that's obvious, and heck, I enjoy writing assembly language 
now and then, but that doesn't make C++, or D, or even Java the root of 
all evil. (matter of fact, I have a soft spot in my heart for Java...but 
that's a different topic :P )

Also, the last bit he says there, the part about: "...just one more dead 
end in our fumbling efforts to communicate with intelligent machines."

What the crap is he talking about? A computer is not an intelligent 
machine...there's no such thing as an intelligent machine. A machine 
does what it's programmed to do, very stupidly. If a computer was 
intelligent, you wouldn't have to write programs for it, or it would 
notice logic errors in your programs as it was running them and fix them 
for you, send you an email letting you know about it, and set up a date 
with a hot chick from the Internet for you (I might note that I would 
not need that, being married myself, but you get the idea).
I mean, seriously...

On the note of the whole tone of the whole paper...he seems like someone 
else I know, who makes up his mind about something right off the bat and 
sticks with it religiously no matter what evidence there is against it, 
or lack of evidence he has to back it up, requiring him to just make 
crap up...or maybe he just likes typing "OOP".

Okay, I gotta stop..I could go for pages...

-- 

-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch
Jan 21 2005
prev sibling next sibling parent Carotinho <carotinobg yahoo.it> writes:
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
Jan 21 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 But today, when we are wiser, is such fervor fruitful? This might sound
 as an utterly academic question, but what happens if we are designing a 
 library? 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?


I sometimes find it annoying to have to subclass to use some GUI toolkits 
(eg Java) so I'm trying to make MinWin OOP neutral. For example here are two 
versions of a program that shows a window with a button in it that brings up 
a modal OK/Cancel dialog and changes the window title based on the choice. 
The OOPS one is slightly nicer, I suppose, but the procedural one has nifty 
nested anonymous delegates.

module minwin.samples.sample7;
import minwin.all;
class MyDialog : Dialog {
  int result;
  this(MyWindow f, char[] str) {
    super(f,str);
    Button clicked;
    Button ok = new Button(this,"OK");
    Button cancel = new Button(this,"Cancel");
    ok.actionDelegate ~= &okCallback;
    cancel.actionDelegate ~= &cancelCallback;
  }
  void okCallback(Component c) {
    MyWindow win = cast(MyWindow)owner;
    win.title = "you hit ok";
    result = 100;
    visible = false;
  }
  void cancelCallback(Component c) {
    MyWindow win = cast(MyWindow)owner;
    win.title = "you hit cancel";
    result = 101;
    visible = false;
  }
}
class MyWindow : Window {
  this(char[] str) {
    super(str);
    Button but = new Button(this,"click me");
    but.actionDelegate ~= &doDialog;
  }
  void doDialog(Component c){
    MyDialog dlg = new MyDialog(this,"hello");
    dlg.visible = true;
    if (dlg.result == 0) {
      title = "you destroyed the dialog";
    }
  }
}
extern (C)
int MinWinMain(Application* app) {
  MyWindow f = new MyWindow("window");
  f.quitOnDestroy = true;
  f.visible = true;
  return app.enterEventLoop();
}


module minwin.samples.sample8;
import minwin.all;
const int OK = 100;
const int CANCEL = 101;
const char[] KEY = "result";
extern (C)
int MinWinMain(Application* app) {
  Window f = new Window("window");
  f.quitOnDestroy = true;
  Button but = new Button(f,"click me");
  but.actionDelegate ~= delegate void (Component c) {
    Window w = cast(Window)c.parent;
    Dialog dlg = new Dialog(w,"hit ok or cancel");
    Button ok = new Button(dlg,"OK");
    ok.cmd = OK;
    Button cancel = new Button(dlg,"Cancel");
    cancel.cmd = CANCEL;
    dlg.commandDelegate ~= delegate void(Component c, int cmd) {
      Dialog dlg = cast(Dialog)c;
      switch (cmd) {
        case OK:
          dlg.owner.title = "you hit ok";
          break;
        case CANCEL:
          dlg.owner.title = "you hit cancel";
          break;
      }
      // store some data on the dialog using run-time application data
      int* data = new int;
      *data = cmd;
      dlg.appdata[KEY] = data;
      // end the dialog modality
      dlg.visible = false;
    };
    dlg.visible = true;
    if ((KEY in dlg.appdata) is null) {
      w.title = "you destroyed the dialog";
    }
  };
  f.visible = true;
  return app.enterEventLoop();
}
Jan 22 2005