Re: Great SWT Program - Java

On Dec 4, 10:37 am, Steve Wampler <swamp...@noao.edu> wrote:
> Different namespaces.

Nope. No scope operator (e.g. int foo::b(int x) {return bar::b(x) +
1}) and shadowing doesn't prevent the issue (b = b + 1 in an inner
scope with b hiding an outer b won't assign the outer b plus one to
the inner b; it will increment the inner b instead).

(C++ code examples used because C++ has namespaces and an explicit
scope operator.)

twerpinator@gmail.com wrote:
> On Dec 4, 10:37 am, Steve Wampler <swamp...@noao.edu> wrote:
>> Different namespaces.
>
> Nope. No scope operator (e.g. int foo::b(int x) {return bar::b(x) +
> 1}) and shadowing doesn't prevent the issue (b = b + 1 in an inner
> scope with b hiding an outer b won't assign the outer b plus one to
> the inner b; it will increment the inner b instead).
>
> (C++ code examples used because C++ has namespaces and an explicit
> scope operator.)

Scope doesn't have to be specified by an operator. There are times
where it can be determined by context. This is one of them.
And C++ isn't shell - why should they behave the same?

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

On Dec 7, 10:44 am, Steve Wampler <swamp...@noao.edu> wrote:
> Scope doesn't have to be specified by an operator. There are times
> where it can be determined by context. This is one of them.

I don't think so. A command name can be either an alias or the name of
a binary or the name of a shell built-in. Those are three scopes,
nested in some order, with alias apparently nested inside the name-of-
binary scope, so aliases hide binary names. But that means a rm alias
always hides the rm binary, unless the latter is specified with /bin/
rm or similarly instead of just rm.

Of course, the other way around, with the name-of-binary scope nested
inside the alias scope, has the effect that an alias named rm is
inaccessible, shadowed by the binary with that name.

So one way around and a rm alias referring to rm is recursive. The
other way around and a rm alias is completely ineffectual.

The situation purported to be true by you seems to be neither, which
shows that we don't simply have scopes nested in some fixed order. At
which point a scope operator is needed to disambiguate and get more
complex behavior, unless you want the behavior to be unpredictable and
counter-intuitive.

bbound@gmail.com wrote:
> On Dec 7, 10:44 am, Steve Wampler <swamp...@noao.edu> wrote:
>> Scope doesn't have to be specified by an operator. There are times
>> where it can be determined by context. This is one of them.
>
> I don't think so. A command name can be either an alias or the name of
> a binary or the name of a shell built-in. Those are three scopes,
> nested in some order, with alias apparently nested inside the name-of-
> binary scope, so aliases hide binary names. But that means a rm alias
> always hides the rm binary, unless the latter is specified with /bin/
> rm or similarly instead of just rm.

Or, alternatively, there are multiple namespaces: aliases and commands
being two of them. So the same name 'rm' can appear as both an alias
and a command. If the name 'rm' is encountered while expanding the
alias 'nm', that context allows the shell to ascertain that the name
is not an alias. Since the writer of the shell code knows that there
is no recursion in alias handling, this determination is straightforward.
[I'm deliberately ignoring shell function names and shell built-ins
for the purpose of simplicity here.]

This alternative has the advantage of exactly describing the behavior
shown previously. Examining the shell code would tell, of course.

--
Steve Wampler -- swampler@noao.edu
The gods that smiled on your birth are now laughing out loud.

On Dec 10, 9:42 am, Steve Wampler <swamp...@noao.edu> wrote:
> bbo...@gmail.com wrote:
> > On Dec 7, 10:44 am, Steve Wampler <swamp...@noao.edu> wrote:
> >> Scope doesn't have to be specified by an operator. There are times
> >> where it can be determined by context. This is one of them.
>
> > I don't think so. A command name can be either an alias or the name of
> > a binary or the name of a shell built-in. Those are three scopes,
> > nested in some order, with alias apparently nested inside the name-of-
> > binary scope, so aliases hide binary names. But that means a rm alias
> > always hides the rm binary, unless the latter is specified with /bin/
> > rm or similarly instead of just rm.
>
> Or, alternatively, there are multiple namespaces

See above. If they're nested, then ever possible nesting order implies
behavior that's inconsistent with your claims in some way. If they're
not, then there'd have to be an explicit scope operator to get at at
least one of them.

[snip remainder of BS]

Circular reasoning now? I was wondering how long it would take for one
of my attackers to think up that particular fallacy and use it
creatively. Assuming what you set out to prove, then unsurprisingly
proving it from that and other premises. :P