Access Modifiers and the variables scope

dev google-group-archive
1

Today I was reading over the Lucee 5 docs. One thing I noticed was Access
Modifiers for variables.

My question is how is this code:

component {
private this.lastName=“Sorglos”; // cannot be accessed from outside
public this.comment=“This is a comment”; // can be accessed from outside
…}

different from

component {
variables.lastName=“Sorglos”; // cannot be accessed from outside
public this.comment=“This is a comment”; // can be accessed from outside
…}

Am I missing something with the this / variables scopes of a component?

Andrew Penhorwood

2

Today I was reading over the Lucee 5 docs. One thing I noticed was Access
Modifiers for variables.
Access Modifiers for variables :: Lucee Documentation

My question is how is this code:

component {
private this.lastName=“Sorglos”; // cannot be accessed from outside
public this.comment=“This is a comment”; // can be accessed from outside
…}

[…]

Am I missing something with the this / variables scopes of a component?

Yeah. Lucee was short of recipes for confusion, so they added that in.

I’d love to know the perceived problem that this is a “solution” to. And
how it seemed sensible to subvert the established notion of public/private
that this/variables have always represented.

Perhaps there’s a good reason. But I think - before Lucee 5 goes out the
door - this functionality should go back in front of the TAG for discussion
& sanity check.

I could understand if in .lucee they had this:

public somePublicVar; // equiv to this.somePublicVar
private somePrivateVar; //equiv to variables.somePrivateVar

Because this follows the precedent set by local scope vs var for function
local variables.

However I don’t think that’s a useful addition to CFML, TBH. We’ve just got
to accept that CFML works in a specific way in this regard, and stop
tinkering with it. That’s what .lucee is supposed to be for.On Monday, 1 February 2016 12:19:04 UTC, Andrew Penhorwood wrote:

3

the idea is to combine the two scopes, variables and this, into one.

so with the absence of the variables scope, we still want to allow to
keep variables as private.On 2/1/2016 5:41 AM, Adam Cameron wrote:

On Monday, 1 February 2016 12:19:04 UTC, Andrew Penhorwood wrote:

Today I was reading over the Lucee 5 docs.  One thing I noticed
was Access Modifiers for variables.
http://docs.lucee.org/guides/lucee-5/access-modifiers.html
<http://docs.lucee.org/guides/lucee-5/access-modifiers.html>

My question is how is this code:

component  {
    private  this.lastName="Sorglos";  // cannot be accessed from outside
    public  this.comment="This is a comment";  // can be accessed from outside
    ...
}


[...]

Am I missing something with the this / variables scopes of a
component?

Yeah. Lucee was short of recipes for confusion, so they added that in.

I’d /love/ to know the perceived problem that this is a “solution” to.
And how it seemed sensible to subvert the established notion of
public/private that this/variables have always represented.

Perhaps there’s a good reason. But I think - before Lucee 5 goes out
the door - this functionality should go back in front of the TAG for
discussion & sanity check.

I could understand if in .lucee they had this:

|
publicsomePublicVar;// equiv to this.somePublicVar
privatesomePrivateVar;//equiv to variables.somePrivateVar
|

Because this follows the precedent set by local scope vs var for
function local variables.

However I don’t think that’s a useful addition to CFML, TBH. We’ve
just got to accept that CFML works in a specific way in this regard,
and stop tinkering with it. That’s what .lucee is supposed to be for.

–
Love Lucee? Become a supporter and be part of the Lucee project today!

You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/dfece93c-e1a6-4e83-ab08-ec495dbf17c4%40googlegroups.com
https://groups.google.com/d/msgid/lucee/dfece93c-e1a6-4e83-ab08-ec495dbf17c4%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

4

I like the access modifier idea. The private keyword should be optional
and the default behavior for anything placed in the THIS scope. The idea
being things are limited and one has to use a modifier to open it up to
more access.

Not sure any of this should be in the CFML side of Lucee. But +1 for a
Lucee language feature.

Andrew PenhorwoodOn Tuesday, February 2, 2016 at 4:48:08 PM UTC-5, Igal wrote:

the idea is to combine the two scopes, variables and this, into one.

so with the absence of the variables scope, we still want to allow to keep
variables as private.

On 2/1/2016 5:41 AM, Adam Cameron wrote:

On Monday, 1 February 2016 12:19:04 UTC, Andrew Penhorwood wrote:

Today I was reading over the Lucee 5 docs. One thing I noticed was
Access Modifiers for variables.
http://docs.lucee.org/guides/lucee-5/access-modifiers.html
Access Modifiers for variables :: Lucee Documentation

My question is how is this code:

component {
private this.lastName=“Sorglos”; // cannot be accessed from outside
public this.comment=“This is a comment”; // can be accessed from outside
…}

[…]

Am I missing something with the this / variables scopes of a component?

Yeah. Lucee was short of recipes for confusion, so they added that in.

I’d love to know the perceived problem that this is a “solution” to.
And how it seemed sensible to subvert the established notion of
public/private that this/variables have always represented.

Perhaps there’s a good reason. But I think - before Lucee 5 goes out the
door - this functionality should go back in front of the TAG for discussion
& sanity check.

I could understand if in .lucee they had this:

public somePublicVar; // equiv to this.somePublicVar
private somePrivateVar; //equiv to variables.somePrivateVar

Because this follows the precedent set by local scope vs var for function
local variables.

However I don’t think that’s a useful addition to CFML, TBH. We’ve just
got to accept that CFML works in a specific way in this regard, and stop
tinkering with it. That’s what .lucee is supposed to be for.

–
Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/dfece93c-e1a6-4e83-ab08-ec495dbf17c4%40googlegroups.com?utm_medium=email&utm_source=footer
https://groups.google.com/d/msgid/lucee/dfece93c-e1a6-4e83-ab08-ec495dbf17c4%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

5

the idea is to combine the two scopes, variables and this, into one.

so with the absence of the variables scope, we still want to allow to keep
variables as private.

That might be the idea, but that’s not what you’ve done. You’ve done this:

private this.lastName=“Sorglos”; // cannot be accessed from outside

public this.comment=“This is a comment”; // can be accessed from outside

And that’s daft.

I’m all for getting rid of the scopes, but if that’s what you want to do
then do that. Don’t do something else, especially something else that is
half-arsed,overlaps existing behaviour whilst at the same time
contradicting it.

Also… stuff like this does not belong in CFML at all. CFML has scopes.
Just deal with that.

If you want to do away with scopes, do it in .lucee. That’d be cool, and
makes sense there.

If you wanted to implement the public / private thing in CFML, then there
should be a syntax rule that one can do this:

public myPublicVar = “something”;

OR one can do this:

this.myPublicVar = “something”;

(and those would be equivalent).

This is analogous to already-implemented handling of using var or using
the local scope. So it makes sense to perpetuate that paradigm.

But THIS would yield a syntax error:

public this.myPublicVar = “something”;

No good comes from this:

public variables.myVar = “something”;

Because it will still need to coexist with

variables.myVar = “something”;

And then subsequent unqualified / uncontextualised usage of variables.myVar later
in the code.

And that just makes things a confusing mess.On Tuesday, 2 February 2016 21:48:08 UTC, Igal wrote: