(http://livejournal.com/users/cmm)

отмазка: мне тож приходят уведомления о его новых статьях, сам не помню на какой имейл и когда подписался, однако-ж с собственному изумлению иногда читаю

(http://livejournal.com/users/brumka)

there!  this storing process, how does it look?

if it looks like this (pseudo-code):

string input = asp.get_input (my_form);

, then what's stopping you from writing this:

infected_string_t input = make_infected_string (asp.get_input (my_form));

?

I must be still missing the real horror of ASP, I guess.

(http://livejournal.com/users/cmm)

of course I am right.
in fact, I'm infallible!

in this case, the point wasn't “people don't use structs”.  the point was “people don't use structs when there is a built-in type {or a preexisting struct or class, for that matter) that is capable of representing the raw physical information needed”.  or, more generally, people don't realize that type checking is there to help them, not to punish them.

> to apply OOD correctly.

it is impossible to practice a religion “correctly”, because correctness is a scientific idea.  though you can certainly practice a religion effectively, productively and in many cases even enjoy the process.

> The entire idea behind objected driven design is just like you said - semantically encoding different types of data in your programs and provide means to facilitate communications to and from these types of data. The only product I have known that provides a full practical implementation of this idea is a C++ compiler.

uh.  well, nevermind, I won't open that pandora's box here.
let's just quite one Alan Key: “I've invented the term 'object-oriented', and C++ is not it”.

> In order to achieve this goal (at least theoretically) in a program, one needs the tool to meet certain criteria and allow to do certain things. If your tool supports only strings and integers - you really can not “make the conceptual leap”.

“really can't” is obviously too strong.  perhaps “find it highly impractical”.

then again, if one's thinking is rigidly constrained by the vocabulary of the specific tool, one has a problem.

on the practical side, many people use smart languages to generate programs in stupid ones.

(http://livejournal.com/users/cmm)

You call a method of the server side object “Request”. This method returns a string. You have to store the result somewhere. You store it in a variable. The variable has a name. You define that name. The author suggests that when defining names, you use a certain naming convention so that when reviewing and maintaining the code everybody knows which HTML should be encoded and which isn't :-)

(http://livejournal.com/users/lake_of_fire)

Dustom ix, dustom! Kalenym zhelezom! ))))

(http://livejournal.com/users/lake_of_fire)

Eeee… I don't think that you are right. If that was so, nobody would have used structs nor would have known to apply OOD correctly.

I'm not sure where the popular and quite irrelevant obsession with derivation and inheritance comes from. must be C++. :)

I don't know why the word “obsession” was used by you in this context. Personally I am not obsessed with derivation. Maybe aggregation. But I digress.

The entire idea behind objected driven design is just like you said - semantically encoding different types of data in your programs and provide means to facilitate communications to and from these types of data. The only product I have known that provides a full practical implementation of this idea is a C++ compiler.

In order to achieve this goal (at least theoretically) in a program, one needs the tool to meet certain criteria and allow to do certain things. If your tool supports only strings and integers - you really can not “make the conceptual leap”.

Perhaps you need to know moreabout server side scripting languages and I need to know more about Perl / Python to make this discussion more fruitful.

Sincerely yours,

Gila

(http://livejournal.com/users/lake_of_fire)

(http://livejournal.com/users/cmm)

(http://livejournal.com/users/cmm)

Zeu, she lo.

As I said before, the ASP is a set of internal server objects which I call in my code.

if so, what prevents you from separating your application logic from the actual input/output in any way you see fit?

:-)))))
In asp/jsp separating logic from input/output is impossible. Not difficult, not quirky, just impossible :-)

Regards

(http://livejournal.com/users/lake_of_fire)