Re: Question concerning object-oriented programming

Thank you for not taking me the wrong way.

On Mar 23, 2:49 am, spinoza1111 <spinoza1...@xxxxxxxxx> wrote:
On Mar 17, 5:20 am, "jehugalea...@xxxxxxxxx" <jehugalea...@xxxxxxxxx>
wrote:





On Mar 8, 10:25 am,spinoza1111<spinoza1...@xxxxxxxxx> wrote:

I haven't done a lot of reading about "design patterns" so this may or
may not be a related issue.

My question is why does it always seem necessary in OO for .Net to
decorate objects with state (class level variables) with a bunch of
extra procedures such as toString() and dispose()?

[My list is longer as seen in my book Build Your Own .Net Language and
Compiler.]

[I will try to ignore replies such as "because you're a dip ***".
Grow up.]

That is: there seems to be a consensus that the ancestor Object should
be without qualities or procedures.

If you close your eyes and someone puts something in your hand, would
you be able to tell what it is? Without fingering it, you might
determine that it is heavy. However, without any other indicator, you
really can't say what it is. That is the point of an object; it is
just a way of handing something to someone. When they are ready to
perform a task on it, they can look at it, feel it, other metaphorical
actions, and determine what it is. This is similar to testing with the
keyword "is". The same goes for interfaces. In my experience, object
is more of a placeholder for a real object, or for syncronization;
someone puts it into something else with the understanding that
someone later will know how to get it back to something useful.

That's an epistemological view. I prefer an ontology as being more
fundamental.

The danger is that if I make objects too feature rich, some clown
won't be able to do something. I don't care since this is my
programming language, not his.

You are asking for a base object that does little or nothing. You are
right about adding a feature preventing someone else from performing a
task. That is life. In most languages incorporating a base object,
there has usually been a toString. Even that is pushing it, for some
people. Like I said, most classes shouldn't override toString(), so
it's a waste. Fortunately, it doesn't cost much for the derived
classes. There's no way to get away from a virtual look-up table.




Whereas I believe that all non-stateless objects should have a Usable
property and an inspect() method. If at the end of the constructor the
inspect() of the state fails to verify key assertions, actual objects
should mark themselves Unusable and thereafter all procedures should
take an early exit, and properties and methods returning values should
return defaults such as zero, a null string, or null.

I totally disagree. It is horrible to think that my code would
continue to run in an error state. I would prefer an exception thrown.

It continues to run, but refuses to do anything. It still exists as a
citizen object but from within admits guilt.

The method that calls it should be expecting something to occur. If it
doesn't, the calling code would either not function properly or it
would need to adapt to the failure. In that case, the calling method
should simply stop doing anything also. Then its calling method. And
so on. Essentially, you would have a no-op application and no idea
what went wrong.


Any class I write has a constructor that verifies the input prior to
instantiating the object. It should be IMPOSSIBLE to create an invalid
object. Your example doesn't even handle the more realistic option

But it is not, is it. Therefore, objects have to refuse to run when
not usable/

Not refuse, explode! They need to tell the caller, the creator, that
an error occurred. Unless you have come up with a new way of handling
this, I can't think of a better way. I mean, this behavior is
partially implementable - you could set a boolean when an error occurs
and wrap all your methods with it. How you deal with return values is
your own nightmare.


where objects become invalid after construction. Again, to inspect
could cost significant time, or be impossible. The main idea behind
algorithms is to find constraints that must ALWAYS be true across all
actions. Classes should be written with the assumption that such
constraints will always be held as true, or exceptions thrown
otherwise. Another option is for methods to return error indicators
and for the class to correct itself (or never be invalidated).
Practice has shown error indicators to be unrealistic for most
projects.

Ontologically you still haven't answered the question, Lenin's
question, what is to be done. If an object knows itself to be
Unusable, what should the first lines of code of each of its Public
procedures do? I say the object should Throw an exception with a
message such as "all power to the Soviets" har har. How is this
materially different from what you want? It's only the object taking
responsibility inside its code for its not being ready for work!

You're losing me here. There is a big difference between doing nothing
and throwing an exception. Refusing to run is not the same as throwing
an exception. And I don't like how you say, "Ready to work"; that
implies it may at some point work. Unless you are checking an async
method every now and then, you should either be waiting for the class
to be ready or you shouldn't really care whether its ready or not.
Instead of calling the method and it dealing with its readiness, write
a method called, AreYouReady. This is a separation of
responsibilities.


I first encountered your "idealism" in assembler code which simply
assumed the needed invariants to obtain and which died, messily, with
a lot of pretty blinking lights when the user supplied bad input. I
thought this sucked then and I still think that code that takes steps
is better.

I know it's "unrealistic" to expect actual programmers to do this,
which is why I'm real glad I don't have to work with actual
programmers any more.



Actual programmers are supposed to write code that verifies input. To
neglect such a responsibility can have negative implications for your
career.


Why should the code of an object instance mindlessly grind on,
allowing itself to be called again and again, when another part of the
code has found an assert violation?

It shouldn't. You should throw an exception. Code is only as mindless
as the person who wrote it, since it doesn't have a mind of its own.
Don't assertions throw exceptions?

OK, then we agree. But I think you are prey to a common failing of the
learned which is the idealist refusal to instantiate and think of
material basis. Or, more precisely, to have different languages for
the shop floor and for the executive suite.

I'm not following you here at all.




"Run time asserts are a waste of time". But Stroustrup says why would
you leave a harbor without lifejackets? Didn't something like that
happen on the Titanic?

I'm not sure if you are saying assertions are good or bad, here. I
assume you are saying they are good and should be listened to. Unless
you catch the exception, the assertions are listened to. But again,
you code should be smart enough to detect an error early on and bomb
out.

Here, the split occurs. What goes on, on the shop floor, is part of
"writing" in Derrida's sense whereas in the executive suite we must
never "speak" of such things.

Are you suggesting that at certain levels of code, you should switch
your paradigm and stop checking for the legality of an object? Again,
experience has showed that the number one reason for paradigm shifts
is premature optimization, which is the root of all evil, according to
some people. If I had a boss, I would expect he would like my code to
be as honest as possible. He wouldn't want to hear that my code was
ignoring bad data. He would like to see that I handled the bad object
and he would probably want a report about why it happened, how to
mitigate it and how soon it can be done.

Derrida spoke about breaking things down to their components,
structuralism and comprehending them from their origins. I'm not sure
where you're coming from.


One can listen (I can listen) to a BBC news story, let's say about the
violation of passport data for Clinton, Obama and McCain. One can
envision (I can envision) how it could have happened in terms,
perhaps, of Rexx, since it's probable that passport data is still on
very large IBM mainframes because IBM has quietly continued to improve
and enhance the mainframe despite the fact that most computer slobs
think it's dead, on behalf of huge organizations like the State
department and CIA...and Rexx is the scripting language for getting
access to "secrets" on IBM mainframes. Despite the need for "secrecy",
Rexx is an alarmingly transparent language in which scripts can print
and parse themselves which does math by default on variable-length
decimal strings, and it's from an internal IBM culture which prized
ease of access for internal people.

Mix this with the low self-esteem and petty bourgeois origin of
programmers, especially programmers invited in by Condi Rice's gofers,
who under Bush have been encouraged to outsource, and the only
surprise is that the breach didn't happen sooner.

But, the BBC is necessarily silent on social class and technology to
the depth needed, with the result that the slobs and thugs who pulled
the stunt have probably already sold the data to the highest bidder,
which is probably John McCain's and *** Cheney's mob.

It was another Watergate, in all probability, and the plumbers here
accessed McCain's records to cover their tracks.

Your language is directly responsible for the systematic loss of
control that people feel...the loss of control YOU felt, Malcolm, when
in a job interview, you crapped out when you criticised a programming
language. The fact is that speech, thought free, is controlled in
Foucault's capillary sense, and we violate the rules, which are always
unwritten by necessity, at our peril...as I violate the rules by using
gude gramer, writing ril gude, and speling (see below).


I recently wrote a paper about breaking the formalities of programming
culture and language-centric culture. Obviously every language has a
sub-language that the experienced tend toward, while avoiding other
nasty language gotchas. Furthermore, programmers are well-known for
jumping on a paradigm and never letting go, until it bites them. The
reason is simple: people do what bites them the least. If you find a
set of patterns that prevent your own stupidity from coming back to
haunt you, you tend toward that pattern.

The well-known expression is, "If the shoe fits". Specifically, I
mean, if you know a common approach to solving the problem, you should
use it. It is more likely to be a success and be understandable by
other people. However, if it starts biting you, shift to a new
strategy. Design patterns are a lot like data structures and
algorithms, in that people have been slowly refining them over the
past decades, solving reoccuring problems.

Unfortunately, the problem with sub-programming languages is that they
lose some of they intuitive nature. Most experienced programmers will
write a safer, probably more efficient way of doing something than a
newbie. However, now only experienced individuals will be able to
fully comprehend the "how" of an algorithm. But, as I am sure you
know, the true benefit of experience is our ability to see code in
chunks of tasks, not as individual lines of code, or what have you.



Therefore Object should expose abstract and unimplemented toString(),
dispose() (which is an issue in .Net), Usable and inspect.

Object would have to be abstract for this to be true. I am sometimes
amazed that you can say new Object() in C#. However, given that the
ToString() method returns a perfectly valid string makes everything
dandy. Again, not all object in C# are Dispose-able. Dispose has a
very special meaning in .NET. It is NOT a destructor! Again, I use

We know this, old boy.

Object as more of a placeholder or even as an indicator. Object is
just where C# says, "This is what all things are guarunteed to
implement. It may not be overly feature rich, but it will make other
things, such as HashTables, easier to implement."

Interesting points. Are Objects rilly real? Wouldn't my "real" object
demand a shadow and more abstract object? I am reminded here of Kant's
distinction between phenomena and noumena. Perhaps I shall discover
that it's impossible to do a good job without a noumenal object such
that my phenomenal Object, which I want to run on earth, giving off
charming little toString() texts (I spell ToString toString because it
is written, by me no less, that "method names must be camelCase").

Object is not a thing, it a small view into a thing. Of course, you
can create a new Object, but then it is just that. However, anything
else is really what it really is, being looked upon through the narrow
view of an object. It is important to grasp that distinction. So, yes,
an Object is rilly real.

If you would please, tell me what a dog is. Not what one dog is, but
what a dog is. We live in abstractions, so why not program in them
too. A specific, real dog is a dog and that dog is also an object.


Must we have things never implemented, or is this petty bourgeois
idealism?

Never implemented? Oh, it's implemented. Again, refer to my previous
statement about sub-languages.


I am in a sense a bare metal kinda guy who toggled in binary machine
code, and for this reason I don't want things to be based on an
idealistic and unimplemented/able foundation.

You can toggle bits and represent a dog in the same program. You can
toggle the dog's bits. Programming languages are about cranking data,
one way or another. Languages are constructed with tools to help make
representing concepts and real things as easily as possible, and to
prevent mistakes.

If you worked in C++ where there is no base object, then you know the
world without it. 99% of the time it makes no difference. Languages
like C# perhaps only introduced such a construct to make up for the
limitations/lack of generics (not really). Perhaps, if you read more
about the evolution of OO frameworks, you will see that the base
Object is profound and more involved; it exists for a very good
reason.


I do know one thing. Math should not be theology. DON'T tell me "you
can't do that for it is blasphemous to the church of math" because
only Allah is akbar. The things of man should never be surrounded by
mysteries.

You seem very religious, or spiritual. Philospy, as my girlfriend
reminded me, is deeply rooted in religion, whether to prove or
disprove, to approve or disapprove. Logic is not made up of rules, it
is made up of axioms. Axioms lead to generalizations. Generalizations
lead to theories and laws. They lead to even more complex things.

Programming, at its core, is purely logical. You can consider a design
pattern as an algorithm to perform long division, or something
similar. If you know anything about math, you know that there are
about 20 different ways to do division, plenty of ways to calculate PI
and the only thing that makes one "better" than the other is how fast
it works.

People didn't make languages and constructs such as design patterns to
generate the 10 commandments; they did it to capture a concept in a
more understandable way.




Theory. Any Object should have a toString() and a palindromic
fromString() which restores the object state from the toString, which
would, in this scenario, create a readable but complete state, perhaps
in XML.

Exposing the state of an object breaks encapsulation. You shouldn't
store and retrieve state information for an encryption algorithm. God
forbid! ToString is more often used than not to display user-relevant
information. It is almost never used to spew out the class's internal
state. Most classes should use the default behavior of ToString.

I shall pay no attention to needs for secrecy because as a programme,
the drive for secrecy destroys knowledge. Somebunny else can worry
about this, like my former co-worker Whit Diffie. Secrecy in America
is destroying habeus corpus. *** secrecy.

Secrecy is what is required when one person out of 6 billion decide
they would like to steal your personal information, steal your
livelihood and steal right to live. Unfortunately, it is more than 1
out of 6 billion. This has nothing to do with encapsulation, really.
You don't want to expose how a class works, simply to thwart other
developers from latching on to things you may change some day. You may
change how your encryption engine works; therefore, you don't hide the
implementation details to maintain secrecy, but to decrease coupling.
.