Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Argument scope

Reply
Thread Tools

Argument scope

 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      12-06-2010
Mike Schilling <(E-Mail Removed)> wrote:
> "Lew" <(E-Mail Removed)> wrote in message
> news:idhr76$j6b$(E-Mail Removed)...
>> BGB wrote:
>>> admittedly, I would also like get/set support and structs, ... (if/when

>> What do you mean by "structs"?

> I'd guess it's a C or C++-like struct: an object all of whose fields are
> public....


In the context of this group, "struct" has been used for a (proposed)
compound of fields that doesn't reside on heap, but *somewhere else*
(such as on the stack with all the logical consequences on its lifetime).

 
Reply With Quote
 
 
 
 
BGB
Guest
Posts: n/a
 
      12-06-2010
On 12/5/2010 11:32 PM, Mike Schilling wrote:
>
>
> "Lew" <(E-Mail Removed)> wrote in message
> news:idhr76$j6b$(E-Mail Removed)...
>> BGB wrote:
>>> admittedly, I would also like get/set support and structs, ... (if/when

>>
>> What do you mean by "structs"?

>
> I'd guess it's a C or C++-like struct: an object all of whose fields are
> public. (In C++, that may be a default rather than a uniform rule. I
> honestly don’t recall.)


except, in this case, I was thinking more C# style struct semantics, as
these would likely be a better fit for Java.

so, the basic description is, it is like a class, except:
it is pass-by-value vs pass-by-reference;
inheritance is not supported;
methods may be supported;
....


an example:
struct Foo
{
public double x, y;
}

Foo a=new Foo();
Foo b;

a.x=3;
a.y=4;
b=a;
b.x=5;

now: a.x=3, a.y=4, b.x=5, b.y=4.


mostly, structs would allow potentially higher performance with some
operations (particularly vector math), since the use of pass-by-value
semantics allows the compiler and VM to more accurately know the
lifespan of objects (vs with classes where the lifespan is potentially
unbounded, and the VM can't statically optimize for the lifetime of any
object which may be potentially captured externally during its lifetime).

there is no need to handle the possibility of capture with a struct,
since it is always passed by value, so anything captured in a variable
is necessarily a copy.


C# also supports passing-by-reference with structs, but at this point
one almost may as well just use classes. in this case, I will also
ignore the possibility of supporting pointers (these would complicate
matters and constrain the implementation).


similarly, properties:

class Bar extends Object
{
private double x, y;

public double X {
get { return x; }
set { x=value; }
}

public double Y {
get { return y; }
set { y=value; }
}

}

which could internally expand to something like:
class Bar extends Object
{
private double x, y;

public double get_X() { return x; }
public void set_X(double value) { x=value; }

public double get_Y() { return y; }
public void set_Y(double value) { y=value; }
}


the main difference is that one can access a field differently:
Bar obj;
double x;

....
x=obj.X;
obj.X=3;

vs, say:
x=obj.getX();
obj.setX(3);


yes... properties are basically just syntax sugar...
 
Reply With Quote
 
 
 
 
BGB
Guest
Posts: n/a
 
      12-06-2010
On 12/6/2010 12:37 AM, Andreas Leitgeb wrote:
> Mike Schilling<(E-Mail Removed)> wrote:
>> "Lew"<(E-Mail Removed)> wrote in message
>> news:idhr76$j6b$(E-Mail Removed)...
>>> BGB wrote:
>>>> admittedly, I would also like get/set support and structs, ... (if/when
>>> What do you mean by "structs"?

>> I'd guess it's a C or C++-like struct: an object all of whose fields are
>> public....

>
> In the context of this group, "struct" has been used for a (proposed)
> compound of fields that doesn't reside on heap, but *somewhere else*
> (such as on the stack with all the logical consequences on its lifetime).
>


yes, what I was thinking would be similar, just focusing primarily on it
being pass-by-value and having a constrained lifetime.

in this case, where it is stored is a secondary issue:
on the stack works (and is a very sane implementation).


on the heap is also possible, but with a few exceptions:
its lifetime remains finite, and it can be readily destroyed (without
having to wait for the GC to do its magic).

an example of the above could be if the struct were handled in a more
"malloc/free" like manner (vs being created and reclaimed some
indeterminate time in the future).

however, an efficient VM would likely just use the stack, since stack
space is allocated and destroyed very quickly.


the issue with normal objects is this:
a naive implementation can't know that they have gone out of scope and
are no longer useful (and have become garbage);
static object scope analysis is problematic and is of limited
effectiveness (all of the code needs to be visible, and any object
potentially captured may be preserved, which is a lot more than may be
actually captured);
naively dividing object references into local and global may itself risk
a number of "false positives", resulting in garbage being leaked onto
the heap, or create some overhead to handle this more precisely
(detecting if the local objects were only referenced by other local
objects and so may be safely freed, or if the local objects may in-fact
be safely freed).

having objects with statically known lifetime simplifies the task of
eliminating them earlier, and thus avoiding potentially notable delays
sometime in the near future.


or such...
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      12-06-2010
Peter Duniho <(E-Mail Removed)> wrote:
> On 12/6/10 12:22 AM, BGB wrote:
>> yes, what I was thinking would be similar, just focusing primarily on it
>> being pass-by-value and having a constrained lifetime.

> All parameters in Java are passed by value. See my other reply.


Indeed, but, unlike objects, structs *could* be passed.

>> in this case, where it is stored is a secondary issue:
>> on the stack works (and is a very sane implementation).

> It's not sane when you declare a value type member within a reference type.
> ...


This makes no sense at all to me, so I guess I just fail to
understand what you meant. Maybe it's a consequence of you
having a different picture of the proposed idea.

My picture of structs would be, that it is mostly a compiler thing.
Declaring a struct would mean declaring a set of variables that are
subsumed with a "meta"-name:
struct Z { int x; double y; } would mean, that whenever I use a
Z-typed variable "z", then the compiler inserts two variables
"z.x" and "z.y". If I make an assignment to z, the compiler would
make individual assignments for z.x and z.y (modulo further optimi-
zations). If a method takes a Z-typed argument, it really takes an
int and a double (each of which, and thusly also the struct, would
have pass-by-value semantics).

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      12-06-2010
On 12/6/2010 1:36 AM, Peter Duniho wrote:
> On 12/5/10 11:55 PM, BGB wrote:
>> except, in this case, I was thinking more C# style struct semantics, as
>> these would likely be a better fit for Java.
>>
>> so, the basic description is, it is like a class, except:
>> it is pass-by-value vs pass-by-reference;
>> inheritance is not supported;
>> methods may be supported;

>
> Hopefully, if Java does gain such a feature, they are more careful about
> the "pass-by-reference" terminology.
>
> Java doesn't have pass-by-reference, and classes (reference types) in
> C#/.NET are passed by _value_ by default. Whether something is passed by
> reference depends not on the data type, but on whether the "ref" or
> "out" keyword is present. Both reference and value types are passed by
> value without either of those keywords, and by reference with either of
> them.
>


well, ok, this is arguing semantics...

I was not writing here about 'ref' or 'out'...


I was thinking of passing objects by reference or by value, not passing
variables or arguments.


if one wants to call them reference-types or value-types instead, either
way.


> And lest anyone get all indignant and start a whole argument about the
> question, I'll include a reminder that we've all already been there,
> done that.
> http://groups.google.com/group/comp....d31b429fdb02a/
>
>
> Twice:
> http://groups.google.com/group/comp....704996edfbf46/
>
>
> Well, actually…lots more than that. But those are the most recent major
> threads on the topic.
> http://groups.google.com/groups?q=gr...y+reference%22
>
>
>> mostly, structs would allow potentially higher performance with some
>> operations (particularly vector math), since the use of pass-by-value
>> semantics allows the compiler and VM to more accurately know the
>> lifespan of objects (vs with classes where the lifespan is potentially
>> unbounded, and the VM can't statically optimize for the lifetime of any
>> object which may be potentially captured externally during its lifetime).

>
> The main thing that value types provide is value type semantics. That
> is, copy-value-on-assignment rather than copy-reference-on-assignment.
> It's as much a program semantics thing as anything else, and allows
> things like a primitive integer type that still inherits from the type
> system's base class (System.Object in .NET, of course would be
> java.lang.Object in Java), and easily copying the value of some data
> structure.
>


well, that is another way of seeing it.


> It can also be a performance boon, especially when it comes to storing
> data structures in arrays, or maintaining them in local variables that
> wind up being allocated on the stack. But at least in .NET, those are
> implementation details, unlikely to change but not guaranteed either.
>
> Unfortunately, many people have confused "value type" in .NET with
> "always allocated on the stack", which of course is not true. Value
> types _may_ be allocated on the stack, but then there's a language
> keyword that allows reference types to be allocated there as well, and
> of course value types wind up in the heap if they are allocated as part
> of a reference type (e.g. an element in an array or a field in a
> reference type). It's a mistake to conflate allocation strategies with
> the value- and reference-type distinction.
>


yep.

well, one could also say "a contiguous block of bytes stored somewhere",
but this need not necessarily be the case either (if it is nowhere in
direct visibility of pointers or of C, it doesn't matter how exactly the
memory is organized, although a contiguous glob of bytes does make some
sense).


>> [...]
>> C# also supports passing-by-reference with structs, but at this point
>> one almost may as well just use classes.

>
> C# supports pass-by-ref with both value types _and_ reference types, and
> by default uses pass-by-ref with neither.
>


more semantics...

nevermind me and terms and words, grr...


>> [...]
>> similarly, properties:
>>
>> class Bar extends Object
>> {
>> private double x, y;
>>
>> public double X {
>> get { return x; }
>> set { x=value; }
>> }
>>
>> public double Y {
>> get { return y; }
>> set { y=value; }
>> }
>>
>> }

>
> Yeah, I tried explaining the pleasures of properties here awhile back.
> It apparently turns out to be one of those things that, if you haven't
> used it, seems like something ridiculous to add to the language (though,
> admittedly I have seen the same reaction to value types as well).
>
> Suffice to say, those are just a couple of features in C# that, in spite
> of how much I do like Java, cause me to strongly favor C# any time I
> have the choice of language to use.
>



yeah, in some ways I like C# more as a language, and a few other things
were done fairly well, but have found I am a bit less of a fan of the
..NET VM as a whole...


meanwhile, I develop my own obscure piece of VM technology, but it is
more of an ad-hoc mess in some ways...

it does support JBC though (and currently the use of standard Java
compilers is my sole means of supporting Java), although it is unlikely
I will have full J2SE support anytime in the near future (the current
aim is for J2ME conformance).

but, I also want my freedom to pursue various implementation and design
options, which is harder with a more "frozen" piece of technology...

a goal will be to also possibly allow some of my other supported
languages to work on JBC (as opposed to each having their own local
bytecode formats and being multiplexed via the VM's core systems). but,
this requires finding good ways of making a lot more features work
through it (and addressing a few of its limitations, ...).


yes, yes, in the end it will probably all amount to nothing, but really,
why does this *always* have to be the concern...

why can't a person just do their own thing and accept full well that it
will probably just amount to nothing in the end anyways, and that
neither change nor relevance matters? (or, maybe, that beyond what one
gets out of it, change may be more of a necessary evil than anything
else... like the lyric "I don't want to change the world, but I don't
want the world to change me...").


but, alas...

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      12-06-2010
On 12/6/2010 2:16 AM, Andreas Leitgeb wrote:
> Peter Duniho<(E-Mail Removed)> wrote:
>> On 12/6/10 12:22 AM, BGB wrote:
>>> yes, what I was thinking would be similar, just focusing primarily on it
>>> being pass-by-value and having a constrained lifetime.

>> All parameters in Java are passed by value. See my other reply.

>
> Indeed, but, unlike objects, structs *could* be passed.
>
>>> in this case, where it is stored is a secondary issue:
>>> on the stack works (and is a very sane implementation).

>> It's not sane when you declare a value type member within a reference type.
>> ...

>
> This makes no sense at all to me, so I guess I just fail to
> understand what you meant. Maybe it's a consequence of you
> having a different picture of the proposed idea.
>
> My picture of structs would be, that it is mostly a compiler thing.
> Declaring a struct would mean declaring a set of variables that are
> subsumed with a "meta"-name:
> struct Z { int x; double y; } would mean, that whenever I use a
> Z-typed variable "z", then the compiler inserts two variables
> "z.x" and "z.y". If I make an assignment to z, the compiler would
> make individual assignments for z.x and z.y (modulo further optimi-
> zations). If a method takes a Z-typed argument, it really takes an
> int and a double (each of which, and thusly also the struct, would
> have pass-by-value semantics).
>


well, although I see this as a possible implementation, I personally
feel that such an implementation strategy is overly constraining, and
would admittedly rather see them supported at the VM level than simply
at the language/compiler level.

hence, my considered implementation strategy takes a somewhat different
form (namely, identifying classes as being structs and adding operations
to facilitate preserving their semantics regardless of proper VM
support), rather than thinking in terms of how to manage a glob of
variables.

in this later form, the VM would be responsible for finding an efficient
way to store and work with them.


or such...
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      12-06-2010
Tom Anderson <(E-Mail Removed)> wrote:
> BufferedWriter out;
> with (out) {
> write("foo");
> newLine();
> write("bar");
> newLine();
> }
> Which basically redefines the implicit target of invocations inside its
> scope from 'this' to something else. It's a little wordier.


Pascal had it already. I learnt Pascal before I got in touch with C,
and bemourned the lack of "with" in C. I'd love to finally see it at
least in Java

>> If an object were designed for sequences of void method-calling, then it
>> should have its methods return "this", instead, so one could do
>> ref.callThis().callThat().callAnother(). ...

> A construction which i hate with a burning passion.
> ...
> How does that have any semantic meaning?


semantic meanings are overrated

PS: there's also:
BufferedWriter _ = ...;
_.doThis(); _.doThat(); ...
or, using short names like "b", or "bw".

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      12-06-2010
BGB <(E-Mail Removed)> wrote:
> I was thinking of passing objects by reference or by value, not passing
> variables or arguments.


Oh, prepare to be flamed for that.

It's really just a language nitpickery.
By using the terms "pass" and "reference" together, you implicitly
have switched from Java-speak to "technical term"-speak, where a
reference is something different from Java's so-called references.

In "technical term"-speak, however, objects aren't "passed" at all -
instead "references" (hmm, shouldn't that be "pointers", then?) are
passed, obviously by value.

I'd really like to know a Java-term to be used instead of "to pass",
such that it would be allowed to say "An object (or possibly none)
is *coffepot* to this method by (Java-)reference."

 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      12-06-2010
Andreas Leitgeb <(E-Mail Removed)> writes:
>In "technical term"-speak, however, objects aren't "passed" at all -
>instead "references" (hmm, shouldn't that be "pointers", then?)


I already posted this many times before:

(...) reference values (...) are pointers

JLS3, 4.3.1.

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      12-06-2010
BGB <(E-Mail Removed)> wrote:
> On 12/6/2010 2:16 AM, Andreas Leitgeb wrote:
>> My picture of structs would be, that it is mostly a compiler thing.
>> Declaring a struct would mean declaring a set of variables that are
>> subsumed with a "meta"-name:
>> struct Z { int x; double y; } would mean, that whenever I use a
>> Z-typed variable "z", then the compiler inserts two variables
>> "z.x" and "z.y". If I make an assignment to z, the compiler would
>> make individual assignments for z.x and z.y (modulo further optimi-
>> zations). If a method takes a Z-typed argument, it really takes an
>> int and a double (each of which, and thusly also the struct, would
>> have pass-by-value semantics).


> well, although I see this as a possible implementation, I personally
> feel that such an implementation strategy is overly constraining, and
> would admittedly rather see them supported at the VM level than simply
> at the language/compiler level.


I see your intention. I just do not believe that it would work out in
a useful way.

> hence, my considered implementation strategy takes a somewhat different
> form (namely, identifying classes as being structs and adding operations
> to facilitate preserving their semantics regardless of proper VM
> support), rather than thinking in terms of how to manage a glob of
> variables.
> in this later form, the VM would be responsible for finding an efficient
> way to store and work with them.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Lexical scope vs. dynamic scope Xah Lee Java 0 02-26-2009 10:08 AM
CSPEC issue: lossing scope (or incorrect scope) in cspec subroutine. balldarrens@gmail.com Perl Misc 0 02-05-2009 08:42 PM
Scope - do I need two identical classes, each with different scope? ann Java 13 09-13-2005 03:07 AM
How do namespace scope and class scope differ? Steven T. Hatton C++ 9 07-19-2005 06:07 PM
IMPORT STATIC; Why is "import static" file scope? Why not class scope? Paul Opal Java 12 10-10-2004 11:01 PM



Advertisments