Re: Question concerning object-oriented programming

On Mar 25, 8:45 am, "jehugalea...@xxxxxxxxx" <jehugalea...@xxxxxxxxx>
wrote:
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

Little but not nothing.

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

I have to decide whether toString() shall be reversible with respect
to a fromString() so that the state of all or most objects, and all
base Objects, can be saved in graphical ASCII characters (or in
Chinese for that matter: some subset of unicode) and restored in all
or most cases.

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.

I have the standard that "all methods, that do not return a value,
shall return bool true or false, true on success, false on failure. If
they think they always succeed or are at a current stage of
implementation stubs, they may return truth".

Nonfunctioning classes, marked as Unusable, take a stronger step. This
is to Throw an error deliberately disrupting the execution path of
their caller.




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

Throw does this nicely. It brings down the house.

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.

Throw is better. It requires the caller to actively participate in a
cover-up.








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.

Objects in my current praxis expose a Usable property which asks, are
you usable.




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.

I have left a professional role as a programmer, as I've said. The
reality on the ground, which I've encountered repeatedly, is that
ERRORS ARE IGNORED.

This is a widespread engineering reality that is generally
undocumented, although University of Chicago anthropologist Diane
Vaughan documents it as "normalized deviance" in her book The
Challenger Launch Decision: precisely because she's not an engineer,
she can disregard engineering *omerta* (institutional silence) on this
matter.

I believe it played a role in the 1980s savings and loan crisis, in
the intelligence failures that led to Sep 11 and the ongoing meltdown
in mortgage securitization. For example, I've learned, informally at
this time, that data processors charged with creating the software for
mortgage securitization (the packaging of mortgages, bought from the
originator, into securities), the keys of the original mortgage and
thus the identity of the debtor is often lost.

A collection of stories about working in Hong Kong, "Sweat and the
City" (Hong Kong Writer's Circle 2006), documents something I saw in
reinsurance software, that supports insurance companies who insure
other insurance providers against big claims. The software often has
to build graphs of policies but in some cases does not search these
graphs to see if they are tree-type, with no cycles such that a path
leads from node (policy) XYZ through other node/policies back to XYZ
such that XYZ is insuring itself...and generating a fee each time
control transits through the cycle, a fee that is often embezzled by
middle managers in on the game...who discipline the programmer who
adds a simple check for this looping.

These "strange loops" appear to be part of the securization crisis.

But what's interesting is that:

(1) Programmers are expected to give lip service to error checking as
a smart career move
(2) Programmers are often disciplined on the job in the real world for
adding extra checks "not requested by the User"
(3) The User as a singular is by definition somewhat not subject to
audit and can cause the programmers to help him defraud the company,
although when the fraud occurs at sufficiently high levels (such as
government financing using public funds, that could be spent on
schools, libraries, and goddamn petting zoos, to rescue private
banks), none dare call it fraud
(4) My evidence seems necessarily anecdotal and louche: a Nosey Parker
anthropology major, a bunch of hard-working Hong Kong part-time
poetasters, and scuttle *** acquired over thirty years. This is
because as Chomsky has pointed out, most professions and most of
what's called "expertise" are conspiracies against the public weal.





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.

See above. Educated middle-class people learn how to use language to
conceal as well as reveal.








"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,

No, I am saying this is what happens.

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.

Real supervisors in MIS are in fact subject to contradictory
pressures. From above those pressures are almost exclusively
fiduciary. From below he hears the programmers clamor for enough time
to do a good job. Almost every real supervisor will listen to the
former type of input.


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.

...without forgetting the original glue that makes social objects work
together to produce results, good and bad. Simple breakdown ignores
contradiction.






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

...

read more »- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

.