Prev: Cornford-Crockford Scope Management - CC Scope Management - CC
Next: Alt text for equations
From: Dmitry A. Soshnikov on 16 Jun 2010 11:26
On 16.06.2010 16:03, VK wrote:
> On Jun 16, 3:31 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com>
> wrote:
>> Now tell me. The author of Ruby -- Yukihiro Matsumoto<URL:http://en.wikipedia.org/wiki/Yukihiro_Matsumoto> -- could he /by his own
>> hands/ just "kill" his language and provide such "insecure" methods?
>> Could he just don't think about anything and create such "ugly" language
>> which (oh-o-o..) has no /"private" keyword for "security"/? Or maybe, he
>> just knew _what is_ encapsulation?
>
> Yukihiro Matsumoto thoughts are his thoughts, I didn't participate in
> Ruby design. He might know what encapsulation must be by CS
> definition. He might not knowing what practical security issues can
> be.

It was an example for you. Repeat, I'm not proving you anything, I just
can explain.

> You didn't answer my question about Java<=> JavaScript interop
> over JSObject and the security/stability issue caused by missing
> encapsulation for Applet generic methods.

You're still trying to treat our discussion as a dispute. Please notice
also our positions: we're exchanging with meanings. I've listened your
meaning, decided that it distinguishes from the my meaning. It has
turned out that the correct meaning of the encapsulation is on my side
(if you want the division on "your" and "my" sides). Should I excuse
before you for that? ;) Who have decided that it's on "my" side? -- The
(1) general theory, (2) the initial document of encapsulation concept
written by inventor, (3) several examples in other languages.

But, repeat, until you'll stop treating the discussion as a dispute, it
is hard to accept the truly meaning. And if you stop treating the
discussion so, you'll see, that there should not be so, that your
position is (sort of) "judging" and I "should" to prove you something
answering your question.

I can answer your questions if you ask me. But please don't treat the
talk that I "should" prove you something (_you_ can (try to) prove me
something in the current position, but not vice-versa (e.g. I can ask
you -- show me any documents where written that the purpose of an
encapsulation is a "security measures from hackers") -- but I don't
wanna such talk). Because if all I explained to you (opening eyes and
showing several examples and explanations from the general theory) is
not needed to you, I let myself not to do this. As I said, the truth
won't be hurt just because someone don't accept/understand it.

> Would you mind to consider
> this case
> http://groups.google.com/group/comp.lang.java.help/browse_frm/thread/dc29f8c3c187b791
> and comment on it:

Yes, sure.

> is it abstraction encapsulation issue as defined by
> you, is it another type of encapsulation issues, is it not the
> encapsulation issue at all?
>

First, you should answer yourself, what will be, if a user of the page
with your applet bridge calls that _public_ methods? Will it hurt
someone else? Why that methods are public? Is it a public interface? If
so, why the user should ask your permission to call them? If you don't
control the "privacy" of that methods and they come from Java applet
class -- then you should answer again the question -- what will be if he
call them.

If this action will destroy all accounts or get all money to she's (I
used "she" :)), then the language (JS in this case) is treated in wrong
way of using. Repeat, if we have dynamic language which simply allows to
modify its code at runtime with the simple approaches (via console or
"javascrpt:" or anything else), then we should expect using of this
language as a useful and convenient _addition_ for the _user_. If user
don't wanna that convenience and want to examine what will be if he call
`init' method again -- and therefore he will _"break" just his own page_
-- then it's she's right.

If your methods still "delete all accounts" or "get all money to she's
account", but you made this with "private" method, then, repeat, the
hacker will use completely other measures, e.g. traffic sniffing, direct
call to your application (besides JS) or methods. But. If your system
can "delete all accounts" or "get all money to she's account" just with
some method call without (sic) crypted authentication and authorization
(and this data also can be sniff on traffic and decoded), then just your
system is build incorrectly.

So, backing to the JavaScript. As a simplest example I can suggest JS
form validators which some people use to check the data before inserting
to database without checking them on the server-side. JS should be
treated as just an _addition_ -- a convenience for the user. If user
breaks it himself (e.g. by simple replacement of a funciton:
form.isValid = function () { return true; }) -- then he makes it
inconvenient for only himself (you'll return the page with errors
checked on the server side to which the user has no access at all). Will
you suggest to make "isValid" static and read-only? OK, he will send the
direct request without your JS at all. But for what all that? If he want
to hack the server -- he should (try to) hack the server with completely
other measures. And please notice, we talk about some "hacker" which _do
not have access to the server code_ but try to hack the server (your JS
which is the addition isn't interesting to him, because he knows, that
if you clever, you'll made all the checks on server).

In contrast a _programmer_ (not a hacker which isn't related with
working with your code) _has access to your code_ (supposing that she
used it locally, but not load from the other source) and can change it
as she wish. If she loads it from the other source, she (a programmer)
still can to update the code via "monkey patching". If you won't prevent
also this -- do not user dynamic languages. But why should you want to
prevent this? Because your system is designed so, that there is magic
method calling which will "delete all accounts" or "get all money to
she's account". Then the problem is just in your system. And programmers
which use your lib can do with a code whatever they want, including
changing "privacy" of class fields if they thought it will be convenient
for them.

So, regarding exactly your example. I think it isn't encapsulation issue
at all, because you deal not even with a programmer, but with some user
which "plays" with this code on shes own page.

>> By the way, why do you used "she" word? I'm just interested from the
>> English language position. Why not "he"?
>
> Just the pc (political correctness) habit. In the US "he" as the
> universal 3rd person was admitted as sexist, so switched to "he/she" -
> "she/he", then to the shortcut "(s)he". Both rightly considered as
> ugly so finally it was decided to use "she" everywhere just to be left
> in peace by pc maniacs. So not be surprised by seeing "she" throughout
> in many US originated manuals. Not to say I am in pc violation fear in
> this NG, just a typing habit. If it irritates you I'll try to control
> it and to use "he" instead.
>

Oh, good to know, thanks. So you use always "she" when meaning
third-party men. OK, will use also.

Dmitry.
From: VK on 16 Jun 2010 13:24
On Jun 16, 7:26 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> But, repeat, until you'll stop treating the discussion as a dispute, it
> is hard to accept the truly meaning.

If you don't see a possibility of a discussion on the matter - because
the indisputable and the only true is yours - then there is a little
point to continue. The Usenet is not a university billboard with the
right by definition profs posts. You see the encapsulation as an
abstraction tool only and anything that is not an abstraction tool is
not the encapsulation by definition - like the Java issue I mentioned.
Your position can be justified by some very reputable sources
including the "canonical" definition by Grady Booch.
The truth is... OK, sorry: my truth is that this approach is the same
extreme as "encapsulation no matter what" you are fighting with. I do
understand why you are pushing it on your students: you want to shake
out from them the "encapsulation==security" paradigm at the early
stage of learning. Yet you maybe do not notice that you throw the baby
out with the bathwater. Again someone - possible me again - will get a
CS fresh graduate who needs an emergency real life dirt load on his/
her theoretical purity. That is not nice of you ;-) :-|

I told you in my previous post that it's all about the semantic. Now -
really, only now - I googled to see if there are some established
terms instead of my custom-made ones. So again: you are only concerned
about the abstraction encapsulation
http://en.wikipedia.org/wiki/Encapsulation_%28computer_science%29#Encapsulation
and only for that you accept the term "encapsulation" as the valid
one.

My definition of the encapsulation is wider than that and the aspect I
might be really concerned in particular projects is the information
hiding encapsulation
http://en.wikipedia.org/wiki/Data_encapsulation
http://en.wikipedia.org/wiki/Information_hiding

And in the aspect of a security related encapsulation as a weird
combination of words you may consider the encapsulating security
payload
http://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload

If you don't want to see it as a discussion because nothing to discuss
then consider it as my votum separatum to your indisputable
resolution. :-) :-|
From: Scott Sauyet on 16 Jun 2010 13:57
Tim Streater wrote:
> In article <hvaqip$1d...(a)news.eternal-september.org>,
>  "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote:
>> On 16.06.2010 16:03, VK wrote:
>>> On Jun 16, 3:31 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com>
>>>> By the way, why do you used "she" word? I'm just interested from the
>>>> English language position. Why not "he"?
>
>>> Just the pc (political correctness) habit. [ ... ]
>
>> Oh, good to know, thanks. So you use always "she" when meaning
>> third-party men. OK, will use also.
>
> No, don't - it's stupid. Only foolish Americans have allowed themselves
> to be bullied in this way.

The old standard of using masculine pronouns for anonymous individuals
has been declining in many English-speaking countries for several
generations. Some people will take offense to the old usage, probably
with reasonable justification. But no consensus has emerged on how to
replace it. As VK said, "he/she" and "(s)he" are monstrosities. My
personal choice is to randomly assign a gender to an unknown
individual, and stick with it while discussing that person. But this
can be disconcerting for those who still use the traditional form:
"How do you know it's a woman?"

It's definitely considered wrong to use a gender known to be incorrect
for a partially anonymous individual. This feels quite wrong: "If any
of the players on the U.S. Men's World Cup team doesn't like it, she
can complain to the authorities." So does this: "An expectant mother
can expect his bulging midriff to attract attention." But for, say,
an anonymous user of a website, either "when the user moves her
mouse..." or "when the user moves his mouse..." would be widely
accepted.

--
Scott
From: VK on 16 Jun 2010 14:14
On Jun 16, 9:57 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> But no consensus has emerged on how to
> replace it.  As VK said, "he/she" and "(s)he" are monstrosities.  My
> personal choice is to randomly assign a gender to an unknown
> individual, and stick with it while discussing that person.  But this
> can be disconcerting for those who still use the traditional form:
> "How do you know it's a woman?"
....
> But for, say,
> an anonymous user of a website, either "when the user moves her
> mouse..." or "when the user moves his mouse..." would be widely
> accepted.

It is OT by thank you for extending your first post: as it would be
hugely unfair to make me anyhow responsible for things introduced by
native speakers. If the ol'good King James bible now considered
politically incorrect by some... http://www.bible-researcher.com/links12.html
I just may suggest if writing a help file or a manual for CA in the US
either say "she", or rephrase for not using 3rd person singular, or
use other tricks from "Gender-Neutral Bible translations" (Jh, Holly
Mother of Lord...)
Not a requirement of any kind, just a suggestion from my personal
experience.
From: Dmitry A. Soshnikov on 16 Jun 2010 15:30
On 16.06.2010 21:24, VK wrote:
> On Jun 16, 7:26 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com>
> wrote:
>> But, repeat, until you'll stop treating the discussion as a dispute, it
>> is hard to accept the truly meaning.
>
> If you don't see a possibility of a discussion on the matter - because
> the indisputable and the only true is yours - then there is a little
> point to continue. The Usenet is not a university billboard with the
> right by definition profs posts.

Nobody said that. If I don't know something and someone explains it to
me, I'm thankful to him, because he upgrades my knowledge. If I am not
right, I accept it and thankful. If I am right -- my "opponent" accepts
my meaning. It was, is and will be so.

> You see the encapsulation as an
> abstraction tool only and anything that is not an abstraction tool is
> not the encapsulation by definition - like the Java issue I mentioned.

I see it as I is. OK, you may see it as you see.

> Your position can be justified by some very reputable sources
> including the "canonical" definition by Grady Booch.

Well, yeah, it seems acceptable explanation.

> The truth is... OK, sorry: my truth is that this approach is the same
> extreme as "encapsulation no matter what" you are fighting with. I do
> understand why you are pushing it on your students: you want to shake
> out from them the "encapsulation==security" paradigm at the early
> stage of learning. Yet you maybe do not notice that you throw the baby
> out with the bathwater. Again someone - possible me again - will get a
> CS fresh graduate who needs an emergency real life dirt load on his/
> her theoretical purity. That is not nice of you ;-) :-|
>

I explain as I read and understood it. It's not me who invented
"encapsulation" concept. So I can just to pass this knowledge to other.
Who interested of course.

> I told you in my previous post that it's all about the semantic. Now -
> really, only now - I googled to see if there are some established
> terms instead of my custom-made ones. So again: you are only concerned
> about the abstraction encapsulation
> http://en.wikipedia.org/wiki/Encapsulation_%28computer_science%29#Encapsulation
> and only for that you accept the term "encapsulation" as the valid
> one.
>

This is main its purpose.

> My definition of the encapsulation is wider than that and the aspect I
> might be really concerned in particular projects is the information
> hiding encapsulation
> http://en.wikipedia.org/wiki/Data_encapsulation
> http://en.wikipedia.org/wiki/Information_hiding
>

Yeah, you can read these two articles (the second one is better as it's
more complete and describes an "encapsulation" from my viewpoint).

> And in the aspect of a security related encapsulation as a weird
> combination of words you may consider the encapsulating security
> payload
> http://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload
>

The word "encapsulation" can be used in any other region of application.
You can invent your own combination of words with this word and the
provide your own meaning.

From the CS viewpoint, "encapsulation" was and is an _increasing of an
abstraction, predicting and localizing the places of internal state
changes to store compact public API_. This is my own definition.

> If you don't want to see it as a discussion because nothing to discuss
> then consider it as my votum separatum to your indisputable
> resolution. :-) :-|

You have complete right on it. OK, thanks for discussion.

Dmitry.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Cornford-Crockford Scope Management - CC Scope Management - CC
Next: Alt text for equations