Access Modifiers and the variables scope

[Andrew Penhorwood]

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

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

[Adam Cameron]

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

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.

[Igal @ Lucee.org]

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.

--
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.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/dfece93c-e1a6-4e83-ab08-ec495dbf17c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Clausen]

Igal,

I was looking at this earlier, when I Andrew’s email came through. Wouldn’t it make sense, though, for the access modifiers to provide an implicit this scoping.

private this.privateVar="foo";

and

public this.publicVar="bar";

seems a bit cumbersome when the access modifier is already at work.

IMHO private privateVar="foo"; ( or just an empty declaration of `private privateVar;’ ) implicitly scoping is clean and matches the function accessibility declarations, as is the case in other dev languages

For what it’s worth, I think access modifiers are a great idea.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/56B123FF.3040004%40lucee.org.

[Igal @ Lucee.org]

Wouldn’t it make sense, though, for the access modifiers to provide an implicit this scoping.

makes sense to me.

@Micha?

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/etPan.56b12818.f32df9f.5c78%40jonclausen-mbp.local.

[Andrew Penhorwood]

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 Penhorwood

[Adam Cameron]

On Tuesday, 2 February 2016 21:48:08 UTC, 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.

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.