component or class

[Michael Offner]

ATM we still use the word "component" for components in the Lucee dialect, should we consider to use the term "class" instead in the Lucee dialect? 

so instead of

component {

}

we do 

class {

}

in our code. we could still support "component" as alias to make the conversion of an existing application easier. 

What do you think?

Micha

[Adam Cameron]

Agree. "class" is the ubiquitous OO term for these things. It wasn't so cool CFML called them component's from the outset.

I've lobbied in the past to get the term changed to "class" for CFML as well, but ppl recoiled in horror and didn't think it was a good use of Adobe's time. Mileage varies, it seems.

Good call, Micha.

-- 
Adam

[Andrew Dixon]

I would agree with class as well.

Kind regards,

Andrew

about.me
mso - Lucee - Member

--
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/5a87ea0b-79d8-4b51-b986-6dae02534d4e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[thorste...@googlemail.com]

I vote for class.

[Jonas Hauß]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijXst%3DRnVkiQVY%3DCZMSjSRv6LC%3DE_eymByBvOBNXqheYBA%40mail.gmail.com.

[Kai Koenig]

Yes, should be class in .lucee

Cheers

Kai

[Jeroen Knoef]

I would only like that with proper constructors. A discussion about constructors was started a while ago, including some proposals. The 'init' convention has served us well, but if something is going to be called a class, I think a proper constructor is required. If 'class' is just an alias for 'component', you might lose the opportunity to do something about this in the future.

[Adam Chapman]

+1 for class.. I always wondered why MM used the term "component"..

[Jesse Shaffer]

I completely agree :)

https://bitbucket.org/lucee/lucee/issue/82/5x-proposal-class-syntax

[Gert Franz]

+1 for me too… maybe we could think about a constructor keyword too?

 

Sincerely
Gert Franz

 

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: ge...@rasia.ch
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/4D305DEF-B694-4568-82C3-73F0BABD13E8%40gmail.com.

[Jean Moniatte]

If component becomes class, shouldn't function become method ?

Thanks,

Jean

On Thu, Apr 23, 2015 at 2:06 PM, Jesse Shaffer <dajest...@gmail.com> wrote:

I completely agree :)

https://bitbucket.org/lucee/lucee/issue/82/5x-proposal-class-syntax

--
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/92bde911-617d-496b-ac2f-11cef12fe4df%40googlegroups.com.

[Simon Hooker]

Definitely in favour of class

[Michael Offner]

@Jeroen

In the Lucee dialect the "init" method is always executed before you get access on the instance and it doesn't matter what the method return you always get the component, so it is like a real constructor. 

we will also discuss in the tech board to add support for listeners that you get access before the constructors are executed.

BTW the final decision about class/component will happen on the tech board.

Micha

On Thu, Apr 23, 2015 at 1:08 PM, Jeroen Knoef <jer...@neoneo.nl> wrote:

I would only like that with proper constructors. A discussion about constructors was started a while ago, including some proposals. The 'init' convention has served us well, but if something is going to be called a class, I think a proper constructor is required. If 'class' is just an alias for 'component', you might lose the opportunity to do something about this in the future.

--

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/601dde84-d298-4725-9b85-2b523e1df5f2%40googlegroups.com.

[Michael Offner]

@adam

I think because you can access them from remote, so you could say it is more than just a class it is a component...

http://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component

maybe Sean Corfield has some insight on this ...

Micha

--

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/48fb6ad2-4457-4820-b1fd-05fbf48d3438%40googlegroups.com.

[Jeroen Knoef]

Thanks, sounds good to me Micha.

 

we will also discuss in the tech board to add support for listeners that you get access before the constructors are executed.

What is the use case for this? Is this related to the earlier discussion about CreateObject()?

 

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/MzOw82hnzEg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAG%2BEEByHZj%3Du5m3%3DV6nEwVreDALRMVAGcae68w6HfD8jMLADdw%40mail.gmail.com.

[Tony Junkes]

+1

[Michael Offner]

yes, the Lucee dialect does not support createObject what allowed to inject code after the body constructor was executed but before init was executed.

the idea is that you can do the following

ObjectNew(component:"Whatever",arguments:[],listener:function(component c){/* here you can manipulate the cfc before the constructors are executed*/})  (the final name of that function also get decided by the tech board).

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/67B32536-2BE5-4996-A064-83CD25ECDA2E%40neoneo.nl.

[Jesse Shaffer]

TBH, I would prefer to get rid of the keyword altogether:

class {
    public any myFunctionName() {

    }
}

[Adam Cameron]

Agreed. What else could a construct

public any myFunctionName() {

}

possibly be, other than a function? It shouldn't need to be flagged as such.

-- 

Adam

[Jeroen Knoef]

+1 for that! (or +infinity if that helps)

 

The keyword is needed (I presume) because all modifiers are optional. You're allowed to write:

 

class {

 

function myFunctionName() {

 

}

 

}

 

Without the keyword, it would be harder for the parser to distinguish between a function declaration and a function call (in the pseudo-constructor). That could be mitigated if one of the modifiers is required, e.g. the return type. Or, the pseudo-constructor is dropped as well, in the Lucee dialect. In that case, there's never any executable code in the class declaration.

 

Many languages do have this keyword btw (Scala for instance has 'def').

 

 

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/MzOw82hnzEg/unsubscribe.
To unsubscribe from this group and all its topics, 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/922d9232-4ae3-4545-846f-3cdba1775734%40googlegroups.com.

[Adam Cameron]

On Thursday, 23 April 2015 15:45:13 UTC+1, Jeroen Knoef wrote:

+1 for that! (or +infinity if that helps)

 

The keyword is needed (I presume) because all modifiers are optional. You're allowed to write:

 

class {

 

function myFunctionName() {

 

}

 

}

 

Without the keyword, it would be harder for the parser to distinguish between a function declaration and a function call (in the pseudo-constructor).

Declaration:

myFunction(){} 

Call:

myFunction()  

A function declaration must be followed by braces. A function call must not.

But, yes, I don't doubt it's harder. But I think the syntax is unambiguous.

Still: Micha or Igal would know better about that... they've often noticed edgecases where weirdo (but legit) code combinations can actually seem like other syntax constructs.

And also: it's not like it's a very exciting suggestion. But a suggestion nonetheless.

-- 

Adam

[Michael Offner]

what's about closures?

susi=function(){};

should we do this?

susi=(){};

this would raise the question if we should only support Lambda functions then (with closure enviroment)...

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/922d9232-4ae3-4545-846f-3cdba1775734%40googlegroups.com.

[Jesse Shaffer]

On Thursday, April 23, 2015 at 11:09:53 AM UTC-5, Micha wrote:

what's about closures?

susi=function(){};

should we do this?

susi=(){};

this would raise the question if we should only support Lambda functions then (with closure enviroment)...

Micha

 

I don't think what I suggested applies to lambdas/anonymous functions - we're only talking about member functions defined in the body of a class.  Outside of a class, then yes, you would need the function keyword.

[Michael Offner]

There is an other problem come to my mind with that for the parser, take this example:

mail(subject="sss",...){

}

this could be a tag invocation (ACF Style) or a function definition.

Of course we should think to get rid of one of the script tag syntaxes anyway in the Lucee dialect.

should the "function" keyword optional or not supported at all inside components?

Micha

--

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/0be6b092-4fef-48ee-a098-73f93344d22e%40googlegroups.com.

[Sean Corfield]

On Apr 23, 2015, at 5:52 AM, Michael Offner <mic...@lucee.org> wrote:

I think because you can access them from remote, so you could say it is more than just a class it is a component...

http://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component

maybe Sean Corfield has some insight on this …

First off it was Allaire’s folks who chose "component". The rewrite from C++ to Java was well underway by the time Macromedia acquired Allaire.

In the early versions of what became CFMX, components were a custom tag library so you wrote:

<cf:component>

<cf:function …>

</cf:function>

</cf:component>

Tightly coupled to this custom tag library was a Spectra-like persistence engine — which was dropped before the first alpha — so they were very much viewed as "components" rather than "classes". You simply couldn’t do real OOP with them and that didn’t seem to be how the Allaire team thought of them.

CFMX 6.1 made it possible to do "real" OOP with these "components" but by then the names were fixed and the golden calf of "backward compatibility" meant we’d never see them changed.

Fast forward over a decade and the world’s a very different place.

My vote is for .lucee to use "class" instead of "component". I’d prefer to drop the "function" keyword in declarations / definitions but I don’t feel strongly about it. And can we change "getComponentMetadata()" to "getClassMetadata()" with this too?

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Michael Offner]

"And can we change "getComponentMetadata()" to "getClassMetadata()" with this too?"

Sure, if we rename to "class", we have to do that renaming everywhere for this dialect:

- function names

- function arguments

- tag attributes

- doc (reference)

- exception messages

...

Tha will be the hard part, specially because for the cfml dialect we cannot change it.

Micha

--
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/67A8AD94-2E83-405B-946C-B1927896265A%40corfield.org.

[Chip Pinkston]

+1 for 'class' instead of 'component'

+1 for 'method' instead of 'function'

I'd like to see making ('method' | 'function') optional rather than just dropping entirely.


Chip.

[Sean Corfield]

On Apr 23, 2015, at 9:48 AM, Chip Pinkston <chippi...@gmail.com> wrote:
> +1 for 'class' instead of 'component'
> +1 for 'method' instead of 'function'

Whilst I’m in favor of renaming component to class, I have NOT in favor of renaming function to method. Here’s why:

function foo( a ) { return a + 1; }

var o = new SomeObject();

o.bar = foo;
o.baz = function ( x ) { return x * 2; };

var b = o.bar( 42 );
var c = o.baz( 13 );

Objects in CFML/Lucee have functions. They’re just regular functions that happen to rely on variables/this scope (which is dynamic and happens at runtime). They’re not some special thing that is different to a "function".

> I'd like to see making ('method' | 'function') optional rather than just dropping entirely.

By all means make "function" optional if it doesn’t mess with the parser too much, but PLEASE don’t call it "method"! Ugh!

[Jesse Shaffer]

I like Jeroen's suggestion in that regard, and will expound upon it:

Options:
1. Disallow non-constant expressions in the immediate body of the class, so that you cannot call a tag there.

2. As soon as you specify an access modifier (public, private, static, abstract), the function keyword becomes optional.

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/MzOw82hnzEg/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAG%2BEEBzBV1oa8Dkn6kz3CX0YCW62jwaYP3h%2B5%3DQxd-BBO%3DMqAA%40mail.gmail.com.

[Michael Offner]

"1. Disallow non-constant expressions in the immediate body of the class, so that you cannot call a tag there."

no support for a constructor in the component body anymore or just limited?

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAMZ7h4gbGRU3C6ud4Qwn4nznyAtX5rPy7sb%3DwA4C_LpWT%2Bjrtg%40mail.gmail.com.

[Jesse Shaffer]

Since the actual constructor is always going to be called, I'd probably err on the side of none at all in the immediate body of the class.  However, the case could be made for simple assignments (limited) being allowed:

class {
    // could be valid - this is a "constant expression" where the value is known at compile time
    this.value = 1;

    // invalid - these are dynamic, and cannot be known at compile time
    this.queryData = queryExecute("select * from somewhere");
    this.data = url.param;

    // invalid - tag execution
    mail subject="instance created" to="some....@individu.al" {
        writeoutput("why would you want emails everytime an instance is made???");
    }

    // invalid - these scopes should not be available here
    application.instance = this;
    request.instance = this;
    session.instance = this;

    // this is kinda tricky, it feels invalid to me - definitely unnecessary as you should be writing this as a member instead of assigning a closure, but it is a "constant expression" so idk...
    this.closure = function() {}
   
    public <however you define the constructor>() {
        // all the above would be valid here...
    }
}  

[Adam Cameron]

On Thursday, 23 April 2015 17:09:53 UTC+1, Micha wrote:

what's about closures?

susi=function(){};

should we do this?

susi=(){};

Why not? as long as the parser can deal with it?

 

this would raise the question if we should only support Lambda functions then (with closure enviroment)...

Do you mean that in the sense that you'll only support functions as expressions (lambdas), not via statements (not lambdas)?

EG this:

f = (){}

But not this:

f(){}

Or do you mean this distinction you make between these two syntaxes currently:

f = function(){} // lambda

f = ()->{} // also a lambda, just with a different syntax

And if "function" was omitted, we've have this:

f = (){}

Which is unfeasibly similar to the "arrow function" syntax above?

?

If it's the former, I think there's place for both statement-based and expression-based functions.

If it's the latter: no, you should only have one of those syntaxes - and it should use closure - but I don't really care which. Although i think the arrow is redundant, if you can parse the code without it. Indeed, if you can parse the code without it, maybe you don't need it for the same thing in the CFML parser?

-- 

Adam

[Adam Cameron]

On Thursday, 23 April 2015 17:13:13 UTC+1, Jesse Shaffer wrote:

Outside of a class, then yes, you would need the function keyword.

Why?

I mean why would it need it?

Wouldn't it be less than ideal to have two separate syntaxes for defining functions?

-- 

Adam

[Adam Cameron]

On Thursday, 23 April 2015 17:38:13 UTC+1, Sean Corfield wrote:

On Apr 23, 2015, at 5:52 AM, Michael Offner <mic...@lucee.org> wrote:

I think because you can access them from remote, so you could say it is more than just a class it is a component...

http://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component

maybe Sean Corfield has some insight on this …

Cheers for the history lesson & insight Sean!

-- 

Adam 

[Adam Cameron]

On Thursday, 23 April 2015 17:58:32 UTC+1, Micha wrote:

"1. Disallow non-constant expressions in the immediate body of the class, so that you cannot call a tag there."

no support for a constructor in the component body anymore or just limited?

If there are proper constructor methods (or those static {} areas as per the new Lucee 5 feature), what would the purpose of code outwith the constructors / methods be?

(other than like import statements, etc)

-- 

Adam

[Jesse Shaffer]

For situations like this:

<cfscript>
/* index.cfm */

// plain jane function - not a closure.
function blah() {
   return 1;
}
</cfscript>

Also, because in general, CFScript is based moreso on ECMAScript.  However, since going into defining a class syntax is new territory, I'm fine with supporting the idea that class member methods do not need the function keyword.  In an effort to avoid scope-creep, I'd say at least for the time being, leave other function definitions alone.

[Adam Cameron]

On Thursday, 23 April 2015 20:15:31 UTC+1, Jesse Shaffer wrote:

For situations like this:

<cfscript>
/* index.cfm */

// plain jane function - not a closure.
function blah() {
   return 1;
}
</cfscript>

Also, because in general, CFScript is based moreso on ECMAScript.  However, since going into defining a class syntax is new territory, I'm fine with supporting the idea that class member methods do not need the function keyword.  In an effort to avoid scope-creep, I'd say at least for the time being, leave other function definitions alone.

Yep, fair enough. I'd not looked closely at the ECMA 6 spec, so was unaware the syntax for methods in classes is different from functions outside of classes.

But - yeah - it's reasonably an existing precedent that CFScript (erm... LuceeScript in this context?) follows ECMA's lead.

Good thinking, Jesse.

-- 

Ada

[Konstantinos Liakos]

+1 for class, removal of the function keyword inside class, deprecation of the pseudo-constructor.