createComponent() / javaProxy() etc

[Adam Cameron]

G'day:

I think these two threads on my blog need more people's input that just Micha & I bickering (which is what it's sinking to):

http://blog.adamcameron.me/2015/04/lucee-5-beta-createcomponent.html

I contend createComponent() is the wrong name for the function, and actually unnecessary. Details in article

http://blog.adamcameron.me/2015/04/lucee-5-beta-phpification-of-cfml.html

I contend that - in addition to the above - javaProxy() and webServiceProxy() are misnamed

I also contend that the Lucee Team need to involve the community before they make decisions like this. It's supposed to be an open source project, after all.

Cheers.

-- 

Adam

[Michael Offner]

Like I said I'm fine with renaming them...., btw by following CFML they should not be called createJavaProxy, they should be called javaProxyNew (what a terrible name!) like arrayNew,structNew,entityNew... :-)

The process of the development of Lucee 5 was special because of the implications with the Railo project. 

All important features we have in Lucee 5 was defined as feature request with The Railo Jira system or Railos user voice or both.

Only exception is createObject...

please have in mind that ALL the changes we did in the language with Lucee 5 was only about 5-10% of the work and the createObject functions are only around 1-2 hours of work, by looking into this features you only scratch the surface.

When you are asking what is Lucee 5 about, the the answer is the complete architectual redoing of the engine. What was a extremely important step for the future of Lucee.

ANY work on the Lucee project is now open source, if you don't like the name of the JavaProxy function do a pull request with a change of the name. If you think the wiki content sucks jump in and improve it. If you think we need to get the technical advisory board running, be my guest you can start it. If you think we need a process in place for doing whatever ... So every suggestion for a improvement are welcome, but please have in mind that they will not magically happening only because you suggest them, it always needs someone to do it. 

There are no sites here, I'm also only part of that community, maybe my voice has more influence than others, but this is because I spend more time on the project than everybody else and  because I'm knowing the project better than everybody else and to make one thing very clear, I have not seen a cent from LAS yet for my work (and Igal as well) and I don't expect to see one in the near future! 

It is easy to complain that the wiki is not existing or minimal, the hard thing is to change that fact, that it was is open source is about! 

So if you are asking for more open source that could be a good starting point! 

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/6962c695-46b7-456f-9820-df98c3de4e4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jean Moniatte]

First I want to thank again Micha and all the Lucee guys. Without you I would probably be doing php right now :-)

While I really hope that Lucee finds the place it deserves in the web dev world, I do not think that it can happen without more leadership. Look at the docs. For the last 3 years the answer has always been "if you are not happy, just do it, it's open source". Then a few people toy with cool tools for a few days, talk about great things and months later Lucee still does not have an official documentation.

I hate to bitch, but we need someone with some kind of ownership in the project to organize things around, with objectives, directions and a plan. If there was a structure, plenty of people would be willing to participate. It is not Micah's job. It's a project manager job, and people will follow and help the right person as long as he has some authority with the project.

My 2 cents.

Jean

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzamBY1uLn-VAQOwmE%2BJ34wP0mdK9tKGD3aWtkySpr0rA%40mail.gmail.com.

[Andrew Dixon]

Your not wrong Jean and I think what Micha is trying to say is he wants people to step up and volunteer to take on these roles within the project. Lucee is open source and the Lucee Association Switzerland (LAS) is just a group of people willing to contribute some of their and/or companies time and money to help move it along but realistically this group is extremely small and part of the point Micha is trying to make is the community need to step up more and contribute time and effort as well. For example, if you wanted to take on the role you describe I'm sure LAS would be more than happy for you to do that and give you the access required to do it, the problem at the moment is very few people are stepping up.

Another example would be this ticket that Adam raised:

https://bitbucket.org/lucee/lucee/issue/280/typo-you-cannot-extend-the-final-component

It is a typo in the source code, so why didn't Adam just fix it and submit a pull request for it? He doesn't need to know Java to fix this, he just needed to search the source for the string, correct it and submit the pull request, but he didn't, he raised an issue ticket for it and Micha has fixed it, but what a waste of Micha's time.

As Adam said on another post today, people sometimes just need to think more!!! :-)

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG-7QUs8zsqk5vbY0wSRjKDaDEjK3VhNYSwFFFxu8vCR94TM2Q%40mail.gmail.com.

[Jean Moniatte]

Thanks Andrew for taking the time.

What's the point of the member companies? Isn't it their role to organize things like documentation? Sure, it is a community effort, with users like me contributing, but it needs to be organized by Lucee and its members to give it some credibility. If not, it will be endless "why don't you do it" threads.

Thanks,

Jean

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijWdaBMq%3DwMuF9y3YQpSKqKUZTV1EnNZxTFWZC%2BZJB9v-w%40mail.gmail.com.

[Adam Cameron]

On Tuesday, 14 April 2015 11:50:01 UTC+1, Andrew Dixon wrote:

Another example would be this ticket that Adam raised:

https://bitbucket.org/lucee/lucee/issue/280/typo-you-cannot-extend-the-final-component

It is a typo in the source code, so why didn't Adam just fix it and submit a pull request for it? He doesn't need to know Java to fix this, he just needed to search the source for the string, correct it and submit the pull request, but he didn't, he raised an issue ticket for it and Micha has fixed it, but what a waste of Micha's time.

In this specific instance whilst I was trying to test Lucee (my job here: tester) I came across a trivial bug. I do not have the source code, do not want the source code, don't know what the project guidelines are as far as testing, don't know how to do a build to test any fix I make (I would never monkey with someone else's code without testing it), so basically cannot run the code.

What I can do, Andrew, is if I spot a trivial issue whilst I'm already busy doing something else is I can raise the issue (which is, in fact, what I have been asked to do in the past), so at least it's kept track of. So that's what I did. And, note, I raised it as trivial. And I in no way indicated that the issue was an important one, or I specifically wanted it fixed.

If Micha then wasted his time fixing it, he's not managing his time properly: there are more important things for him to be getting on with.

 

As Adam said on another post today, people sometimes just need to think more!!! :-)

Well... yes Andrew. Indeed.

Do you know what I'm not doing whilst I'm needing to justify my actions in this sort of thread? Testing Lucee.

-- 

Adam

[Adam Cameron]

On Tuesday, 14 April 2015 00:51:31 UTC+1, Micha wrote:

ANY work on the Lucee project is now open source, if you don't like the name of the JavaProxy function do a pull request with a change of the name.

That's not a very well-thought-through suggestion. You clearly thought it was a good name, so it would be completely inappropriate for me to unilaterally decide the function name needs changing, and then go change it (pull req needing approval notwithstanding). What makes sense in situations like this is to do exactly what has been done: discuss it. Although as I suggested: discussing it before hand would have been more sensible.

Not all issues need to be solved by hiding one's head in code, Micha.

 

If you think the wiki content sucks jump in and improve it.

Where I actually have the wherewithal to do so: I do.

However this is a specious suggestion in the given context as the updates to the wiki we're discussing is details of the new work you've done, and (as discussed elsewhere), the community can't simply magic-up documentation for work you have done in private.

 

If you think we need to get the technical advisory board running, be my guest you can start it.

This is also completely specious. I cannot do that, can I? Because I'm not an Association Member, I have authority at all, and for a technical advisory board to work it can't just be some people sitting around going "well it'd be better if it was done this way" if there's no buy-in from the people doing the implementation.

 

 

There are no sites here, I'm also only part of that community, maybe my voice has more influence than others, but this is because I spend more time on the project than everybody else and  because I'm knowing the project better than everybody else

That's not true at all.

 

 and to make one thing very clear, I have not seen a cent from LAS yet for my work (and Igal as well) and I don't expect to see one in the near future! 

Well I feel bad for you in that regard, but that was your choice, I guess. And is completely irrelevant to this discussion.

I don't get paid for any of the work I do for the CFML community either. Which is, I think, pretty much how it works in a community.

 

It is easy to complain that the wiki is not existing or minimal, the hard thing is to change that fact,

No, it really isn't. All it takes is for the appropriate person to get on with it and do it. 

-- 

Adam

[Michael Offner]

between the lines

Micha

On Tue, Apr 14, 2015 at 2:28 PM, Adam Cameron <camero...@gmail.com> wrote:

On Tuesday, 14 April 2015 00:51:31 UTC+1, Micha wrote:

ANY work on the Lucee project is now open source, if you don't like the name of the JavaProxy function do a pull request with a change of the name.

That's not a very well-thought-through suggestion. You clearly thought it was a good name,

i never said that

 

so it would be completely inappropriate for me to unilaterally decide the function name needs changing, and then go change it (pull req needing approval notwithstanding). What makes sense in situations like this is to do exactly what has been done: discuss it. Although as I suggested: discussing it before hand would have been more sensible.

everybody agreed (including me) that "createComponent" is a bad name, we discussed a lot and i never sai that JavaProxy or Webservice proxy is a good name, in the end the onyl thing we disagreed was the role of createObject and the init function.

For most decision we raise a discussion in the mailing list and then in the end domeone has to decide how we do it, but we always try to involve the community

 

Not all issues need to be solved by hiding one's head in code, Micha.

right, i did not know that

 

 

If you think the wiki content sucks jump in and improve it.

Where I actually have the wherewithal to do so: I do.

you have a lot of knowlege to improbe a lot and you always can ask me

 

However this is a specious suggestion in the given context as the updates to the wiki we're discussing is details of the new work you've done, and (as discussed elsewhere), the community can't simply magic-up documentation for work you have done in private.

So you have no clue about this new features? Of course you have, you already have a lot more knowlege as it is documented in the wiki

 

 

If you think we need to get the technical advisory board running, be my guest you can start it.

This is also completely specious. I cannot do that, can I? Because I'm not an Association Member, I have authority at all, and for a technical advisory board to work it can't just be some people sitting around going "well it'd be better if it was done this way" if there's no buy-in from the people doing the implementation.

never said you should not involve LAS with that ;-) Simply ask LAS if it is ok that you start this and that you take the lead with it, you would get a ok for sure, we simply would define some base rule for it ...

So first step ask...

 

 

 

There are no sites here, I'm also only part of that community, maybe my voice has more influence than others, but this is because I spend more time on the project than everybody else and  because I'm knowing the project better than everybody else

That's not true at all.

What exactly is not true with that?

 

 

 and to make one thing very clear, I have not seen a cent from LAS yet for my work (and Igal as well) and I don't expect to see one in the near future! 

Well I feel bad for you in that regard, but that was your choice, I guess. And is completely irrelevant to this discussion.

I just want to make clear that i don't own you anything and that it is not my job to do anything like you suggested multiple time.

 

I don't get paid for any of the work I do for the CFML community either. Which is, I think, pretty much how it works in a community.

right, but you dont spend 3-4 days a week only for that project

 

 

It is easy to complain that the wiki is not existing or minimal, the hard thing is to change that fact,

No, it really isn't. All it takes is for the appropriate person to get on with it and do it. 

did you raise your hand for this?

 

-- 

Adam

--
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/631b1ba7-d2c3-4e23-9b01-96fc26bd2486%40googlegroups.com.

[Michael Offner]

coming back to the topic, sorry for going off like this ...

CreateComponent

I agree that is a bad name, it was the shorthand for createObject("component", but it is not very well chosen.

CreateObject is for sure a very good name, but the implementation has some flaws i will explain in detail in an upcoming blog post, only this extend that function is not really an option without breaking backward compatibility.

So my suggestions are (in order i like them):

- ObjectNew (like ArrrayNew, EntityNew,StructNew,...) 

- createInstance

- loadComponent

- instantiateComponent

JavaProxy

i have coosen this name to follow the pattern of the only existing Java function in CFML "JavaCast".

My suggestions are  (in order i like them):

- JavaNew

- JavaProxyNew

- createJavaProxy

WebserviceProxy

i have chosen this name to reflect the name "JavaProxy"

My suggestions are (in order i like them):

- WebserviceProxyNew

- createWebServiceProxy

- WebserviceClientNew

- createWebserviceClient

What do you think?

Micha

[Michael van Leest]

Looking at the current naming convention, I would suggest objectNew() as well.

Concerning JavaProxy and WebserviceProxy, I have no preference.

Maybe a bit off topic, the createObject(). Is it an idea to default the type to "component"? Or be able to set a default for createObject in the Application/server?

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBzMawvPZowLig3ZRDM%3D3QTaRW5TZALc3J-GtYV4MY9FRA%40mail.gmail.com.

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

--

Michael van Leest

[Andrew Penhorwood]

I always use createObject() when using cfc's.  My preference would be createInstance().  That does the best job of describing what is happening.  We are creating an instance of a component.  I have mixed feelings on automatically calling the init() method.  Most of my components have init() methods but they don't always return an instance of the component.  Not a show stopper but code will need to be reviewed before moving to newer versions of Lucee.

Andrew Penhorwood

[Julian Halliwell]

I always use New with non-persistent components (which always have an
init method returning the instance), EntityNew() with ORM entities and
CreateObject() with java classes.

"New" feels right to me, so I'd vote for:

ObjectNew
JavaNew
(Don't do much with web services. WebserviceClientNew sounds clearer
to me, but WebserviceProxyNew may be more accurate.)

Julian
http://cfsimplicity.com/

[Alex Skinner]

I think

objectNew()

javaObjectNew()

webServiceNew()

The whole proxy thing to me is over detail with regard to the implementation that is frankly of little interest to the person calling

A

--
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/CAC_5Vopx%2B12R32xQ-iifRkjxfgN65C_dMs3o8-5acGZDjS75Gw%40mail.gmail.com.

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

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Jon Clausen]

If we’re going to be creating new functions, maybe standardizing some conventions on function naming would be in order.  Looking at the current function list for CMFL (http://www.luceedocs.org/functions),  the functions use many different conventions:

Verb prefix:

verb[type]Noun()  - i.e. createODBCDate() or createObject()

Noun prefix with verb appendix:

nounVerb() - e.g. fileOpen()

Transformers:

typeDescriptorNewType - e.g. arrayToList()

Verb only:

verb() - i.e. encrypt() or duplicate()

Verb Descriptor and Type:

verbForType() - e.g.  encodeForXML()

Noun prefix with adjective appendix (and optional type):

noun[type]Adjective()  - e.g. arrayNew();

There are more, of course, and Alex’s recommendations would be the noun[type]Adjective(), which makes total sense, but doesn’t match the existing or verbType() or verbTypeNoun() conventions uses to create complex objects.  Only simple or native containers currently use noun[type]Adjective() - arrayNew(), structNew(), queryNew().

I would be in favor of moving to that type of syntax instead of a verbType() syntax which tends to be more verbose, but I’d like to see those conventions applied consistently as the language evolves - otherwise we end up like PHP where the function name conventions are all over the map and I never know if the “needle” comes before the “haystack” when searching or evaluating strings and objects.

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5WT%2B5DuE_ahnRPfO9DnX2J2kxjUNfyKFwKnaeBMMFyToQ%40mail.gmail.com.

[Michael Offner]

 I have mixed feelings on automatically calling the init() method.  Most of my components have init() methods but they don't always return an instance of the component.

That is not a problem when "init" has no return type at all.

only the following is a problem for that case

function init(){

   return "Susi"; 

}

So only if you explicitly return something else

We did this btw for compatibility to ACF, but only for the CFML dialect.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/586a6fa0-2dc7-4923-92eb-e017da837985%40googlegroups.com.

[Michael Offner]

"that is frankly of little interest to the person calling"

Ii see a lot of wrong doing in that aspect, people use that wrong what is produing problems and also a lot of overhead.

Because of that I had the impression that a little bit more clarification would not hurt.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5WT%2B5DuE_ahnRPfO9DnX2J2kxjUNfyKFwKnaeBMMFyToQ%40mail.gmail.com.

[Jesse Shaffer]

Since we're talking about objects, why not implement what you're talking about in an object-oriented manner instead of BIFs?

/* org.lucee.cfml.Object */
component {

    public function init(required string clazz, any constructorArgs=[], string initMethod="", string package="") {
        if (len(initMethod)) {
            return createObject("component", clazz)[initMethod](argumentCollection=constructorArgs);
        } else {
            return new "#clazz#"(argumentCollection=constructorArgs);
        }
    }

}

/* org.lucee.cfml.JavaObject */
component {

    public function init(required string clazz, array constructorArgs=[], array classPath=[]) {
        var obj = arraylen(classPath) ? createObject("java", clazz, classPath)
                                      : createObject("java", clazz)
                                      ;
        var args = constructorArgs;
        switch(arrayLen(constructorArgs)) {
            case  0: obj = obj.init(); break;
            case  1: obj = obj.init(args[1]); break;
            case  2: obj = obj.init(args[1],args[2]); break;
            case  3: obj = obj.init(args[1],args[2],args[3]); break;
            case  4: obj = obj.init(args[1],args[2],args[3],args[4]); break;
            // case N: ...ad nauseum...

            default:
                var _args = [];
                for (i=1; i <= arraylen(args); i++)
                    _args.append("args[#i#]");
                evaluate("obj = obj.init(#arrayToList(_args,",")#)");
            break;
        }


        return obj;
    }

}

/* ditto for WebServiceObject */

/* index.cfm */
<cfscript>
   sb = new JavaObject("java.lang.StringBuilder", ["initial string"]);
   sb.append(", now appended!");
   str = sb.toString();

   componentName = "my.Component";
   dynamicComponent = new Object(componentName);
   dynamicComponent = new Object(componentName, {named:"args", work:"here"});
   dynamicComponent = new Object(componentName, ["use","custom","constructor"], "__constructor");

   websvc = new WebServiceObject(...);
</cfscript>

[Jesse Shaffer]

Or, for Lucee 5:

/* org.lucee.cfml.ObjectFactory */
component {    
    public static function Java(required string clazz, array constructorArgs=[], array classPath=[]) { ... }
    public static function Component(required string clazz, any constructorArgs=[], string initMethod="", string package="") { ... }
    public static function WebService(...) { ... }
}


/* index.cfm */
<cfscript>
   sb = ObjectFactory::Java("java.lang.StringBuilder", ["initial string"]);

   sb.append(", now appended!");
   str = sb.toString();

   componentName = "my.Component";

   dynamicComponent = ObjectFactory::Component(componentName);
   dynamicComponent = ObjectFactory::Component(componentName, {named:"args", work:"here"});
   dynamicComponent = ObjectFactory::Component(componentName, ["use","custom","constructor"], "__constructor");

   websvc = ObjectFactory::WebService(...);
</cfscript>

[Andrew Dixon]

I was just reading through the post and as I was reading I pretty much had come up with the same list as Alex before I saw his, so my vote is for these as they make most sense to me and clearly (from my point of view) explain what they are doing. No idea what the word "proxy" is meant to mean in the context of these function calls. To me you are not proxying anything, you are creating a object of a class (Java) or a web service (SOAP). If you therefore want to be really clear you could use webServiceObjectNew() for the web service one, but I'm still not sure why you can't have just one function, objectNew(), and specify the type in that, like you do with createObject, but I guess the upcoming blog post will explain this.

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5WT%2B5DuE_ahnRPfO9DnX2J2kxjUNfyKFwKnaeBMMFyToQ%40mail.gmail.com.

[Peter Boughton]

For dynamic component names, ObjectNew or initComponent.

For Java, I'd prefer no more complexity than we get with new Cfc(args)
- in the Railo days this idea was floated:

new java:ClassName

And I'd still like something to that effect, with of course the ability
to add (args) and automatically call the matching constructor.

[Adam Cameron]

On Wednesday, 15 April 2015 21:53:35 UTC+1, Andrew Dixon wrote:

 No idea what the word "proxy" is meant to mean in the context of these function calls. To me you are not proxying anything, you are creating a object of a class (Java) or a web service (SOAP). 

I've been mulling this over. Andrew you are dead right. Including the word "proxy" in these function names is incorrect. Under the hood Lucee needs to do proxying stuff to expose the Java object to CFML, but from a CFML perspective what is returned is a Java object. The under-the-hood implementation details should not bleed out into the language here.

So: createJavaObject().

Now... one must separate my next comment from any recollection of my current undertaking to get loadComponent() pushed back into createObject()...

The more I think about the undertakings here, the more I think actually the best solution FOR CFML would be to get rid of this function (the Java one) and push the functionality back into createObject(). createObject() is the best name for all this functionality, as *from a CFML perspective* that's what the function is doing.

createWebsServiceProxy() makes sense to me though. Because *from a CFML perspective*, that's what you're getting. The web service is the HTTP address: the object one creates here is a proxy to that.

But what is CFML really gaining from this exercise? Nothing. It's not gaining anything. We're just moving stuff around. Indeed it's actually a net loss for CFML developers because Micha is suggesting deprecating the createObject() functionality, which really means ideally we have to update our code to not use it (which comes with a not insubstantial cost!), as well as retrain our brains. For no gain. This is not a win. Oh, and it stops being ColdFusion compatible.

This is basically an exercise which is purely for Micha's benefit, not the CFML community's. How about Micha does what he likes in .lucee files, where the slate is clean, and just leaves well-enough alone in CFML? Even I wouldn't complain about retasking createObject() in .lucee files because there's no precedent to preserve. That said, the function names would still need work, because the same shortfalls would still apply there as it does in the current situation. But I'd have no problem with createObject() always calling init(), createJavaObject() being specific for Java objects, and createWebServiceProxy() being specific for web services. That makes sense. And doesn't the .lucee concept exists specifically for this sort of thing? Are we making a mistake making any of these changes in the CFML language here? Hmmm...

-- 

Adam

[Andrew Dixon]

Couple of things:

The web service is the HTTP address: the object one creates here is a proxy to that.

Emm, this is used to connect to SOAP (Simple Object Access Protocol) web services, so I'm sorry it doesn't return a proxy it returns an object, the give away is in the second word of the name of the protocol!!! :-)

Micha is suggesting deprecating the createObject() functionality

I think stuff is getting lost in translation here. English is not Micha's first language, and while his English is head and shoulders above my Swiss, because for me that would be zero, I think sometimes he uses the wrong words. At least he didn't say "depreciated"!!! 

I will try to get an LAS official position out on this ASAP.

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/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com.

[Adam Cameron]

On Saturday, 18 April 2015 18:20:26 UTC+1, Andrew Dixon wrote:

Couple of things:

The web service is the HTTP address: the object one creates here is a proxy to that.

Emm, this is used to connect to SOAP (Simple Object Access Protocol) web services, so I'm sorry it doesn't return a proxy it returns an object, the give away is in the second word of the name of the protocol!!! :-)

You need to keep reading all the way to the end of the name of the protocol <---- that's the very word there.

It's a protocol to connect to (remote) objects. On the CFML end you have a proxy for that object. You're not calling methods on the remote object directly - one would need to do that via an HTTP call, or natively on the remote computer - you're calling methods on the proxy which then translates that into an HTTP request (and a bunch of other tedious crap), and sends it, and handles the response converting it back into CFML.

So it's... err... a proxy for the actual object.

:-p

And thanks regarding the other stuff.

-- 

Adam

[Andrew Dixon]

Answer on the ticket:

https://bitbucket.org/lucee/lucee/issue/282/javaproxy-and-webserviceproxy-poorly-named

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/b4402173-edc5-4088-94b5-bfe94d8b99c0%40googlegroups.com.

[Michael Offner]

"from a CFML perspective what is returned is a Java object"

That is the reason I have used the word proxy in the first place, because this is wrong and most people use this functionality wrong what leads to overhead in their code.

Sean did a perfect explanation in a comment in your blog (http://blog.adamcameron.me/2015/04/survey-results-quick-oo-terminology.html) what is going on with this function I will not repeat that.

CreateObject("Java",...) is a very smart implementation then in Java you cannot produce objects from all classes, for example when the constructors are private you can't* (back at the Singelton example and why createObject is bad, but that is an other story ;-) ).

Take this example:

System=createObject("Java","java.lang.System");

Dump(System.nanoTime());

This code never produces a object from type "java.lang.System", this is only a proxy for the "System" class. In fact you cannot* produce a object from the class "System".

Micha

*in Java you can modifie access modifiers at runtime what makes it possible to invoke methods/constructors that are normally not accessible from the current location, as long the security setting allow this.

--

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/1102ffc9-419e-423a-be9b-f89277b96b18%40googlegroups.com.

[Adam Cameron]

On Saturday, 18 April 2015 20:32:38 UTC+1, Micha wrote:

"from a CFML perspective what is returned is a Java object"

That is the reason I have used the word proxy in the first place, because this is wrong and most people use this functionality wrong what leads to overhead in their code.

No.

What the function is intended to do is return an instance of a Java object.

In that I can go createObject("java", "java.lang.String") and then use that object anywhere Java expects a string demonstrates this to be the case. And before you start citing String as a bad example, it was just an example.

If under the hood you need to horse around with proxies and all other sorts of magic to make it work is simply irrelevant as far as CFML goes. It's a Java object in the context of CFML.

You do make a point that you do some clever stuff (or at least emulate the clever stuff Adobe had already done, let's be honest) it exposing static methods via the same function. But if anything this is where the shortfall in createObject() lies. If to leverage a static method one needs to use createOBJECT(), then - yes - that's wrong. But in general, for instantiatable (!) objects, what it's doing is creating an object. But that aside, CFML doesn't make the distinction between the two cases, and this is fine.

If there are performance issues with this approach to creating Java objects, then this is your issue to fix, and is - again - irrelevant to CFML.

You not longer seem to be able to see where your implementation of CFML stops and actual CFML starts. The mere fact you need to do [something] in Java to provide CFML functionality doesn't mean you need to explain it at CFML level in the naming of the CFML constructs. You've lost touch of what CFML is.

-- 

Adam

[Michael Offner]

No that is a good example let me extend it a little bit:

str=createObject("java", "java.lang.String").valueOf(true);

Again no object from type String was produced with createobject, it only produces a proxy objects to a class

But if I do this:

String=createObject("java", "java.lang.String");

String.length();

It produces an instance of string in the second line and then it calls an instance method, problem in every future call to this instance that is inside the proxy has to go through the proxy object that is still around it, it is like a door keeper that always check if we have a static call or not. 

we cannot change that fact, then you can still do this as well:

str=String.init();// create I a instance from the proxy

So the best is to use it as follows:

String=createObject("java", "java.lang.String");

empty=String.init();

str=String.init("Susi");

Only use it to call static method or the create instances. 

And if you need only one instance you do:

str=createObject("java", "java.lang.String").init();

So technically there is no question, createObject-Java does not produce a object from the class requested. The only question is, is this relevant for the users using this function.

To be honest I was undecided from beginning about this, I think for someone heavily relay on this it is relevenat, but for most users it is not.

So I think there is no right or wrong here, so I decided to rename the function to JavaNew, not javaProxyNew or javaObjectNew.

I have not given the name JavaObjectNew for 2 reasons.

1. Again, it is not producing a object and I try to avoid to actievely make this misconception.

2. The function JavaCast is not named cast2JavaObject, it also not speaks from objects.

Micha

Am Samstag, 18. April 2015 schrieb Adam Cameron :

--

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/1f9740b4-677f-432c-9527-e72910034e8b%40googlegroups.com.

[Adam Cameron]

I didn't even read all that (well: yeah I did, but only once, which is a coupla times fewer than I usually read posts here).

You're demonstrating my point: the quibbles you are having are all about how you need to do stuff under the hood. No-one cares mate. Sorry.

In CFML one calls createObject("java") to get a Java object (or access to static methods of a Java class, yeah, we get it). That's it. All the rest if it is relevant to the underlying code, but not to CFML.

I'm not trivialising CFML devs when I say this, or molly-coddling them etc, but the language doesn't make these distinctions that you happen to know exist within your implementation.

Like I said: you've lost track of where your implementation code ends and where CFML begins.

-- 

Adam

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

[Michael Offner]

I did CFML long before I have started Railo and I always have made this distinction, so if you speak for CFML devs you are not speaking for me and everyone I have reached this ;-)

If you read to the end you will see that I already agreed with you that this distinction doesn't matter...

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAOPrabVwiWFOoET8oKtt_B5kzP%2BFSCEcVNnqT_Um0XgcOYr8CA%40mail.gmail.com.

[Adam Cameron]

On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:

I did CFML long before I have started Railo and I always have made this distinction, so if you speak for CFML devs you are not speaking for me and everyone I have reached this ;-)

Really Micha?

You and your pals back whenever were wringing your hands and going "but it's not a Java object, it's merely a proxy to a Java object. And don't get me started on static methods".

Fuck off. Of course you weren't.

 

If you read to the end you will see that I already agreed with you that this distinction doesn't matter...

Yep, read it now. Missed it first time.

So you identified it as a non-issue, but you still decided to meddle with it? What's wrong with you, man? Seriously. Actually seriously: why are you making CFML language decisions on this project?

-- 

Adam

[denstar]

On 4/18/15 3:28 PM, Adam Cameron wrote:
> I didn't even read all that (well: yeah I did, but only once, which is a
> coupla times fewer than I usually read posts here).

I think we'd get further if you tried to understand what Micha is
saying, instead of being so focused on what you see the issue to be, to
the exclusion of salient bits of information.

This is about the "under the hood" as much as it is about what is "above
the hood" -- it's sorta like an intake which pokes through the hood.

At least for the java <-> cf stuff, AFAICT.

> In CFML one calls createObject("java") to get a Java object (or access
> to static methods of a Java class, yeah, we get it). That's it. All the
> rest if it is relevant to the underlying code, but not to CFML.

I don't get it. Are you talking about createObject or the new (heh)
functions?

> I'm not trivialising CFML /devs/ when I say this, or molly-coddling them
> etc, but the *language* doesn't make these distinctions that you happen

> to know exist within your implementation.

I think in general you're right, but if we're talking about cf/java the
distinctions do matter. At least a little. Moreso for people that use
it more-- so I like the idea of clear naming with the new functions.

> Like I said: you've lost track of where your implementation code ends
> and where CFML begins.

I lost track between createComponent and createObject.

-Den

[Michael Offner]

Don't call me a liar!

--

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/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com.

[denstar]

On 4/18/15 4:20 PM, Adam Cameron wrote:
>
>
> On Saturday, 18 April 2015 23:12:44 UTC+1, Micha wrote:
>
> I did CFML long before I have started Railo and I always have made
> this distinction, so if you speak for CFML devs you are not speaking
> for me and everyone I have reached this ;-)
>
> Really Micha?

Dude-- Chill. Out.

> You and your pals back whenever were wringing your hands and going "but

> it's not a Java object, it's merely a /proxy/ to a Java object. And
> don't get me started on /static methods/".
>
> Fuck /off/. Of course you weren't.
>

If anybody was... I mean the guy wrote a CFML interpreter.

When MX came out I was all up in there-- way way more* than most. It's
OK if you weren't, but enough with the attitude already.

*holy crap did digging into the underlying JasperReports implementation
teach me a bunch. And I'm still learning new stuff, years later! Wow!

>
> If you read to the end you will see that I already agreed with you
> that this distinction doesn't matter...
>
> Yep, read it now. Missed it first time.
>
> So you identified it as a non-issue, but you still decided to meddle

> with it? What's wrong with you, man? Seriously. Actually /seriously/:

> why are you making CFML language decisions on this project?

What's wrong with you, man? Srsly. Did you forget who yer talking to?

Please stop with the holier than thou, armchair-uber-coder nonsense.

You. Have. The. Power. (POIDH == Pull-request or it didn't happen)

-Den "the power of Grayskull" Uno

[Kai Koenig]

Ok people, can everyone please calm down for a moment and take their hands off the keyboard.

I was following this thread very closely and both sides have a bunch of good arguments.

1. Micha’s technical arguments about how createObject works in various scenarios are absolutely correct. It’s weird and in some instances inconsistent when you look at it from a Java developer’s point of view.

Now, the question is — would this warrant a change in Lucee’s interperation of CFML? I don’t think so, to be honest. And this leads into:

2. Adam’s points are valid, too — the vast majority of CFML developers don’t give a damn crap about what happens below the CFML language level. All they care about is: CreateObject(“java”,…) gives _some thing_ that they can use to call Java functions. That’s the reality and I think a good point of “language design” is to take this history into account.

Changes like the one discussed here can totally be done in the .lucee version of the language, go for it. But don’t break _a lot_ of existing CFML code that exists out there.

The reality is: If I want to write proper OO- and Java-code, I actually use Java. If I want to or need to use a functional language, I use Clojure. Don’t try to bend CFML into something it isn’t and most likely never will be - it doesn’t create an incentive for people to use it at all imho.

On another, more general note: 

The Lucee Foundation urgently needs a language advisory board. Micha, as much as I love and respect your work and ideas, I don’t think the way forward should be that a lot of language spec decisions are being made by 1 or 2 people behind the scenes. However the Lucee Foundation wants to implement this is not up to me to decide. Certainly your big-$-paying-members should have some votes/access to that, if you make it available to solely them though, you’ll risk alienate the “community” of people using it beyond the likes of those 5-6 companies.

Cheers

Kai

--
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/0646f4e8-25df-40f1-805f-c763f1d56734%40googlegroups.com.

[Steven Neiland]

+1 To everything Kai said. In particular the urgent need for a language advisory board.

[denstar]

On 4/18/15 5:38 PM, Kai Koenig wrote:
> Ok people, can everyone please calm down for a moment and take their
> hands off the keyboard.

Ok, the armchair-uber-coder comment was a bit much.

Only one participant is "playing rough" though, and frankly I've had
enough of it.

Crap like that is what makes some devs throw in the towel-- it needs to
be addressed when it gets out of hand.

-Den

[denstar]

On 4/18/15 5:38 PM, Kai Koenig wrote:

...

> 2. Adam’s points are valid, too — the vast majority of CFML developers
> don’t give a damn crap about what happens below the CFML language level.
> All they care about is: CreateObject(“java”,…) gives _some thing_ that
> they can use to call Java functions. That’s the reality and I think a
> good point of “language design” is to take this history into account.
>
> Changes like the one discussed here can totally be done in the .lucee
> version of the language, go for it. But don’t break _a lot_ of existing
> CFML code that exists out there.

Ok, I'm pretty oblivious, so forgive me, but isn't the discussion about
adding new functions versus just "overloading" createObject?

From a language lexer-parser type of perspective, there is more of a
possibility of breaking code by overloading createObject than there is
when adding new functions. That's a given.

When dealing with Java, distinction comes with the territory, as by
definition we're not using CFML per se. Separating things a bit doesn't
seem like a bad idea-- at least not one that should be talked past, over
and over again.

> The reality is: If I want to write proper OO- and Java-code, I actually
> use Java. If I want to or need to use a functional language, I use
> Clojure. Don’t try to bend CFML into something it isn’t and most likely
> never will be - it doesn’t create an incentive for people to use it at
> all imho.

I didn't think Micha was trying to bend CFML into anything it isn't,
rather, it seemed like he was proposing an option that let it be better,
without potentially breaking a bunch of code. (Which he has a proven
track record of doing, BTW)

Am I mistaken? Was Micha proposing changing createObject? I think I
saw him saying he'd rather promote something better. Adam is proposing
bending CFML-- in a backwards-compatible manner, but still.

(Unless I missed something, which is totes possible.)

>
> On another, more general note:
>
> The Lucee Foundation urgently needs a language advisory board. Micha, as
> much as I love and respect your work and ideas, I don’t think the way
> forward should be that a lot of language spec decisions are being made
> by 1 or 2 people behind the scenes. However the Lucee Foundation wants
> to implement this is not up to me to decide. Certainly your
> big-$-paying-members should have some votes/access to that, if you make
> it available to solely them though, you’ll risk alienate the “community”
> of people using it beyond the likes of those 5-6 companies.

It's not like Micha is unreasonable, or doesn't listen. He asked for
input in the first place. Code by committee doesn't magically produce
reasonable outcomes-- it takes real involvement and discussion and
whatnot (productive, constructive communication from the various
stakeholders). Treating each other with respect doesn't hurt.

-Den

[Michael Offner]

Ok people, can everyone please calm down for a moment and take their hands off the keyboard.

Im not sure if i'm now allowed to write or if i have to wait a little bit ... ;-)

But don’t break _a lot_ of existing CFML code that exists out there.

I would never allow that!!!!

CreateObject is not touced at all, it is only deprecated (what only has a small influence on the documentation) , it needs a lot that i remove a deprecated functionality.

I only remove a deprecated functionality if nearly nobody use it and there is a possible harm with it. 

I was for example considering to remove <cfservlet> what was never supported in Railo/Lucee (it only throws a "not supported exception") but it is still in the core (only CFML) because it does no harm.

The Lucee Foundation urgently needs a language advisory board. Micha, as much as I love and respect your work and ideas, I don’t think the way forward should be that a lot of language spec decisions are being made by 1 or 2 people behind the scenes. However the Lucee Foundation wants to implement this is not up to me to decide. Certainly your big-$-paying-members should have some votes/access to that, if you make it available to solely them though, you’ll risk alienate the “community” of people using it beyond the likes of those 5-6 companies.

This will come for sure, we simply had no time to get it in motion yet.

Every of our members will have a seat in it as defined in our "member benefits" and we will also invite community members for the board.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/181A3F2E-66DC-4951-9C60-8352C1D8A534%40gmail.com.

[Adam Cameron]

On Sunday, 19 April 2015 00:08:14 UTC+1, Micha wrote:

Don't call me a liar!

Huh?

This:

"but it's not a Java object, it's merely a proxy to a Java object. And don't get me started on static methods". 

So that is the way the CFML conversation went. Back then.

[boggle]

OK then.

-- 

Adam

[Sean Corfield]

On Apr 18, 2015, at 5:47 PM, Michael Offner <mic...@lucee.org> wrote:
> CreateObject is not touced at all, it is only deprecated (what only has a small influence on the documentation)

If you deprecate createObject() then there is no way for people to write portable, cross-engine code unless they use a feature that is deprecated in one of the engines. That basically says you are "deprecating portability".

Deprecation says "don’t use this - it’s a bad way to write code".

Deprecation says "change your code to use this other construct". A construct that is not portable.

I’m sorry, but that’s just not an acceptable situation to put library and framework authors in.

Since the fork, the tone of this mailing list has become more and more like Open BlueDragon: "we (the language developers) don’t like features A, B, and C so we’re introducing non-portable, incompatible features X, Y, and Z and telling people to use those".

The Lucee fork effectively killed Railo. That’s fair enough, it was your code to decide what to do with. There are still 2,000 folks on the Railo mailing list and virtually zero activity — 32 posts in April so far compared to normal monthly traffic of 400-500 posts. But there are only just over 500 people on this mailing list. So you haven’t migrated people to Lucee, you’ve just cut the community to a quarter of its size. That’s… terrible. For comparison, there are still over 700 people on the OpenBD mailing list despite "no one" using it.

Your documentation around Lucee 5 has been appalling. Almost every single new feature failed to work the way the documentation said and some features still aren’t documented. Now you’ve implemented objectNew() after telling us you’d implement loadComponent() and the documentation is still wrong. How are we supposed to know what to test when you can’t tell us?

At World Singles, I migrated our DEV setup from Railo to Lucee 4.5, at launch, with plans to migrate QA and production soon after. Now that looks like a dead end and we’d need, instead, to migrate to Lucee 5 which is not a drop in replacement (indeed, the documentation for the 4.5 -> 5 upgrade is minimal at best and poorly written so I have no confidence in even attempting to script that upgrade). The lack of a roadmap and the lack of any clear communication around the project at all (except for some of Andrew Dixon’s work) is extremely disappointing. It really doesn’t inspire confidence.

This latest kerfuffle over createObject() has been the final nail in the coffin for me.

I closed out our Railo to Lucee migration ticket as "Will Not Fix" and I closed out a couple of other tickets that concerned Lucee 5, OSGi and changing with infrastructure as "Will Not Fix" as well.

At this point, I can’t envisage moving our servers to Lucee unless LAS seriously gets its act together — and right now I couldn’t recommend Lucee to anyone else either, in good conscience.

I hope you turn the project around — and soon — and maybe it’ll become something worth considering in the future but everything I’ve seen here over the last couple of months has further convinced me that World Singles’ decision to move away from CFML was the right thing to do, and now we’ll just accelerate that...

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)

[Kai Koenig]

But don’t break _a lot_ of existing CFML code that exists out there.

I would never allow that!!!!

CreateObject is not touced at all, it is only deprecated (what only has a small influence on the documentation) , it needs a lot that i remove a deprecated functionality.

I only remove a deprecated functionality if nearly nobody use it and there is a possible harm with it. 

I was for example considering to remove <cfservlet> what was never supported in Railo/Lucee (it only throws a "not supported exception") but it is still in the core (only CFML) because it does no harm.

By deprecating a feature you’re telling the intended audience that this feature is outdated and the “old” or “bad” way of writing code. It also might or might not be removed at any time.

Even worse: you’re deprecating the feature for no good reason. Yes, looking at it with the eyes of a Java developer I’d agree: It’s confusing. It’s stupid and a collection of probably accidentally created functionality back from the days in ACF 6. 

But: to be frank - if I have to write cross-CFML server code, I don’t want to deal with the fact that Lucee might at some point get rid of CreateObject — which works and does its job just fine — just for the sake of a language cleanup that (in this particular instance/discussion) I think shouldn’t happen in the CFML version of Lucee in the first place. 

Solution: change it in your new language version .lucee, problem solved.

Cheers

Kai

[Geoff Bowers]

This is a language thing -- its pure semantics.  I can't honestly see what the fuss is.

createObject() or any other element of CFML will never be removed unless Adobe decides to remove this from the language. Compatibility is a core focus of the Lucee community -- that will never change.

Based on the history of CFML it is a good bet that createObject() will never be removed.

What @micha is trying to say -- i believe -- is that Lucee will not attempt to extend or improve createObject().  And Lucee would prefer if there were better options than createObject() but there are not, and there will likely never be while Adobe controls CFML.

In order to improve on createObject() we have no choice but to create a new set of functions. What these functions are and how they work is something that should be discussed.

Lets not run amok with wild stories of "createObject() will be removed and break all existing CFML apps".

> Solution: change it in your new language version .lucee, problem solved.

This is exactly what is being proposed. And if its deemed worthwhile, new non-ACF functions could be made available in the CFML dialect.

GB

[Sean Corfield]

On Sat, Apr 18, 2015 at 10:34 PM, Geoff Bowers <mod...@daemon.com.au> wrote:

Based on the history of CFML it is a good bet that createObject() will never be removed.

Then do not deprecate it. It sends the wrong message.

 

What @micha is trying to say -- i believe -- is that Lucee will not attempt to extend or improve createObject().

He doesn't need to deprecate the function to take that position. There's plenty of CFML features that absolutely shouldn't be extended or improved -- but should not be deprecated.

 

In order to improve on createObject() we have no choice but to create a new set of functions.

BS.

 

Lets not run amok with wild stories of "createObject() will be removed and break all existing CFML apps".

Requiring library and framework authors to use a deprecated language feature in order to write portable code is a bad path to go down.

--

Sean A Corfield -- (904) 302-SEAN

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

World Singles, LLC. -- http://worldsingles.com/

[Kai Koenig]

100% agree with Sean on all the points below.

Cheers

Kai

--
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/CAD4thx9ASSoMgytSk1FFp%3Dw-0VBMD_Bes5Vcs%2BMJJ2fmJgUx3g%40mail.gmail.com.

[Adam Cameron]

On Sunday, 19 April 2015 07:28:31 UTC+1, Kai Koenig wrote:

100% agree with Sean on all the points below.

Me too. Especially this one:

 

In order to improve on createObject() we have no choice but to create a new set of functions.

BS.

-- 

Adam 

[Michael Offner]

Removing the deprecated flag then also mean to remove this new functions from the CFML dialect, then having both makes no sense. This means also to include the new functionality javaNew (loading by bundle definition) and webserviceNew (add addional arguments like user/pass) has to go into createObject. We will form the tech advisory board next week an decide over this next week.

@sean I'm sorry to hear that of course it is your decision. I did my best to have a as good as possible doc in place, I'm sorry this was not enough. 

Since the switch to Lucee our resources are very limited, we will try to improve the doc as fast as possible. Btw the doc was updated with the new function yesterday. It would help if you or someone else would point out what pieces you miss in the doc, if you can.

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/2a2f0e0a-6191-4407-9309-7c32bec00d07%40googlegroups.com.

[denstar]

On 4/19/15 12:12 AM, Sean Corfield wrote:
> On Sat, Apr 18, 2015 at 10:34 PM, Geoff Bowers wrote:
>
> Based on the history of CFML it is a good bet that *createObject()
> will never be removed*.

>
> Then do not deprecate it. It sends the wrong message.
>

Deprecate != some kind of deadline for discontinuation, per se.

It can, but in general, at a bare-minimum, it means "there are better
ways of doing this". At least in practice. And with precedence, as
Micha mentioned.

The sky is not falling. Things are the same as they have ever been, for
good or for ill (but let's keep pulling for good, and maybe even
better). I wish I'd been able to keep the momentum going myself --
those installers are needed, and I know how much everyone misses my
witty banter when I don't post -- but Lucee is not doomed due to the
issues that have been raised thus far, and the excitement and lovey
dovey will be back. Things are gonna change (again), I can feel it.

...

> Lets not run amok with wild stories of "createObject() will be
> removed and break all existing CFML apps".
>
> Requiring library and framework authors to use a deprecated language
> feature in order to write portable code is a bad path to go down.

I don't think this is really about portability.

Modifying createObject, vs. encouraging the use of namesAreHard(), makes
for code that is harder to port-- you'd need a regex grep to find the
difference without a language parser, vs. a simple grep. The error
message would be something harder to grok, for instance (I've always
loved the error handling in CFML).

That's one of the things that gets me about this thread... it's not that
the ideas are bad, it's just that the supporting arguments seem to be
more subtext than substance, and there's plenty of substance we could be
focused on.

-Den

[Adam Cameron]

On Sunday, 19 April 2015 08:16:48 UTC+1, Micha wrote:

Context:

[from Sean]:

Your documentation around Lucee 5 has been appalling. Almost every single new feature failed to work the way the documentation said and some features still aren’t documented. Now you’ve implemented objectNew() after telling us you’d implement loadComponent() and the documentation is still wrong. How are we supposed to know what to test when you can’t tell us? 

 

@sean I'm sorry to hear that of course it is your decision. I did my best to have a as good as possible doc in place, I'm sorry this was not enough. 

Since the switch to Lucee our resources are very limited, we will try to improve the doc as fast as possible. Btw the doc was updated with the new function yesterday. It would help if you or someone else would point out what pieces you miss in the doc, if you can.

The issue I think is that you deal with docs as separate to the functionality: it shouldn't be. Any piece of functionality is not "complete" (to whatever level is appropriate, alpha, beta, release) until the whole thing is done, including appropriate docs. So if you've not done the docs for a feature: you don't ship the feature until you have (where "ship" might mean "include in an alpha or beta"). Alpha docs can be scratchy notes; beta-quality docs need to be good enough for the beta-users to actually get a handle on what you've done and how to test it. It's only the final docs that need to be polished. But that'll be less work if the docs are done iteratively too.

Resource-wise this means a coupla things:

* you will release fewer features, but they'll be finished, understandable and usable. This is better than just chucking a bunch of undocumented "features" out there which people can't actually use so as to even be able to provide feedback.

* you need to publicly expose the work you're undertaking. This needs to take the form of detailing the problem being addressed, how the work solves the problems, and what the acceptance criteria are for the solution to be considered "done". If you do this, people in the community can help you with it. I can take rough Swiss-German-English notes and turn them into decent docs. As can Andrew. As can any number of other people. You'll also get to brain-pool the solution. To flog a dead horse as an example... the naming of these functions could have been sorted out at the planning stage, and save having to re-work and save pissing people off when you turn-out seemingly half-baked undocumented work.

You complain that people don't help (I'm not contesting that). But your approach to your work really makes you your own worst enemy here. Not to mention it is a pretty "professionally-immature" way to do work.

Look mate it's not the end of the world and I know written words seem harsher than spoken ones because written words seem more "official" or something. But stuff like this needs to be said. And they need to be either further discussed (to finetune the goals), or they need to simply be acted upon. The presentation of this beta has been subpar, and it is hurting your project (you can declare "pot/kettle" here if you like, but you have less excuse for hurting your own project!). It needs sorting out.

-- 

Adam

[Steven Durette]

Den: Deprecate != some kind of deadline for discontinuation, per se.

Actually it does. The term deprecated means that no new changes will be made to the functionality and that it will be removed within the next two major versions (<sarcasm>Thanks a lot Microsoft</sarcasm>). It also says that if Adobe added functionality that Lucee would never pick up those changes because it is slated for no change and removal.
The term deprecated has evolved and therefore we all have to be careful when it is used.

Steve

Sent from my iPhone

[Matt Levine]

I'm personally ok with learning that createObject has been deprecated, but won't be removed.   Kind of a deprecated with an *.   However, it seems like for some people it crosses a red line.  Perhaps the deprecation could be removed in favor of creating a very simple top level style guide that discourages it's use.   Or even simply put a note in the Lucee createObject documentation that describes the differing opinions.  Basically switch from saying that it's "deprecated but won't be removed" to it's  "supported but not encouraged" .  To me it seems like basically the same thing.

I also agree with Adam that that it only really matters within Lucee's cfml support.  When it comes to the Lucee dialect it doesn't really matter.

-Matt

[denstar]

What "deprecated" means in practice varies by project and parlance.
Microsoft's definition does not apply everywhere, neither does Java's.
Plenty of projects have had deprecated bits of API around for years...
I'm not saying that's good or bad, it's just how it is.

I've found the comment about the deprecation to be the de-facto
definition-- "deprecated - only around for < 1.3 backwards compat" or
"deprecated - will be removed in version 2", for example.

That said, and to malapropriate Hamlet-- to deprecate or not to
deprecate, that is not the question. =)

I mean, that's one of the questions, however I was commenting more on
process than specifics. I'm a big fan of constructive communication,
which Adam does not seem to be-- and he posts /so often/ it's effecting
the tone of the list. I don't want him to stop posting, I want him to
take some of what he's prescribing for others. (If wants were fonts,
we'd all have Lexicon.)

This post won't really help, as it's doing exactly the same thing-- if I
was practicing what I preach I'd be bumping a couple of the positive
posts that have come through this week, extolling teh virtues... how
amazing it is that we are where we are... OMG version 5 *LIVES*! and
talking about content instead of tone... maybe answering a question or
two... leading by example vs. preaching, basically. But screw it, the
world needs sticks too. =)

-Den

[Jon Clausen]

Thanks, Denny, for this post. I couldn't agree more. This list has been getting a bit toxic of late and, while I think the discussions around deprecation and backward compatibility are really important (I've used or been involved with a fair number of OSS projects that died because they were so focused on dogma that they discarded backward compatibility with each release), I think the manner in which the community approaches these discussions is as important, and will, ultimately, be a large part of the public "face" of the project.

> --
> 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/5533EE3A.8010205%40gmail.com.

[Sean Corfield]

On Apr 19, 2015, at 1:34 AM, denstar <vallia...@gmail.com> wrote:

Modifying createObject, vs. encouraging the use of namesAreHard(), makes
for code that is harder to port-- you'd need a regex grep to find the
difference without a language parser, vs. a simple grep.

When I talk about portable code, I mean code — like FW/1, ColdBox, etc — that needs to run unchanged on multiple platforms. I’m not talking about changing ACF-compatible code to run on Lucee. Libraries and frameworks need to run identically on ACF, Railo, Lucee without code changes. And without being forced to use features that one of those engines has deprecated.

there's plenty of substance we could be focused on.

Adam tried to get Micha to focus on substance but Micha refused to answer the specific, substance-based question. Your flowery lets-all-hug-and-get-along responses aren’t exactly helping keeping things focused on substance either.

Sean Corfield -- (904) 302-SEAN

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

[denstar]

On 4/19/15 2:50 PM, Sean Corfield wrote:

> On Apr 19, 2015, at 1:34 AM, denstar wrote:
>> Modifying createObject, vs. encouraging the use of namesAreHard(), makes
>> for code that is harder to port-- you'd need a regex grep to find the
>> difference without a language parser, vs. a simple grep.
>
> When I talk about portable code, I mean code — like FW/1, ColdBox, etc —
> that needs to run unchanged on multiple platforms. I’m not talking about
> changing ACF-compatible code to run on Lucee. Libraries and frameworks

> need to run identically on ACF, Railo, Lucee without code changes. *And

> without being forced to use features that one of those engines has

> deprecated*.

We can and should have a discussion about deprecation. I've stated what
I feel to be the salient bits regarding the issue:

While "deprecate" can mean "don't use this, it's dangerous", it can also
mean "use this if you want, but there is a better way". The key, I
feel, is in the comment about the specific deprecation.

(One of the awesome new things that Micha has added is some compiler
output. One of many many awesome improvements to the language.)

I get the "without code changes" bit, however the "without using
deprecated features" (functions for which a better alternative exists)
bit is unfeasible-- there are already a ton of "better ways" to do
things in Lucee. Deprecation is a way of communicating this to people,
while not breaking code.

Deprecation isn't *bad*. It is a way to move the language forward. It
seems like deprecation is being interpreted as a breaking change in and
of itself, which is not what it means by any definition.

Micha has presented what I feel to be compelling reasons to deprecate
createObject. For what it's worth, it's been deprecated in my mind for
a grip already. The idea of communicating the idea doesn't bother me.

I'm a framework friendly, cross-platform and
in-general-compatibility-and-agnosticality advocate kind of guy myself,
so had the proposal, or new functions, been breaking changes, I would
have had a problem too... that's not what's going on though.

>> there's plenty of substance we could be focused on.
>
> Adam tried to get Micha to focus on substance but Micha refused to
> answer the specific, substance-based question. Your flowery
> lets-all-hug-and-get-along responses aren’t exactly helping keeping
> things focused on substance either.

Micha has valiantly and repeatedly answered the questions, and has
already said that the language advisory deal will be a priority. I
personally think working together in a constructive manner will be just
as important "there" as it is "here". The same problems need to be
solved-- forming a committee won't magically resolve them.

When even one person is being confrontational, it has a deleterious
effect on the solution process as a whole.

Shout out to Micha for staying profesh, and keeping his cool way more
than the average Joe would have under the same circumstances. I am
acutely aware that we wouldn't be here if it weren't for him, and what
he and others have done to breath new life into a language I love.

Ave Imperator, vibro te salutant (A play on an AC/DC song about ROCK'N)
-Den

[Sean Corfield]

On Apr 19, 2015, at 3:37 PM, denstar <vallia...@gmail.com> wrote:

I get the "without code changes" bit, however the "without using
deprecated features" (functions for which a better alternative exists)
bit is unfeasible-- there are already a ton of "better ways" to do
things in Lucee.  Deprecation is a way of communicating this to people,
while not breaking code.

This is the first time a CFML engine vendor has deprecated a feature that library/framework vendors have to use in order to write portable code. That’s why I classify this as "Lucee is deprecating portability".

If both engines had a compatible better way, I’d be fine with this. That’s not the case.

Lucee is forcing me to write code that depends on deprecated features in order to run that code unchanged on multiple engines. That is a bad thing.

[denstar]

On 4/19/15 4:46 PM, Sean Corfield wrote:

> This is the first time a CFML engine vendor has deprecated a feature

> that library/framework vendors *have to use in order to write portable
> code*. That’s why I classify this as "Lucee is deprecating portability".
>
> If both engines had a *compatible* better way, I’d be fine with this.

> That’s not the case.
>

> Lucee is *forcing* me to write code that depends on deprecated features
> in order to run that code unchanged on multiple engines. *That* is a bad
> thing.

We are *already* using features that are deprecated in Lucee if we're
writing for cross-compat with ACF, according to the "a better
alternative exists" meaning of the term deprecated. This has been true
for years, and hasn't broken any code. Deprecated != non-compatible.

If deprecation was *breaking* things somehow, I'd agree that it would be
bad, but that is not what is happening, and not what deprecated means.

For me, Micha and a few stalwart companions have and are defining the
future of CFML, going on several years now. You have said much the
same, as have many others. Cross-engine compatibility (within reason)
has *always been important*, and deprecating X doesn't mean that
importance is suddenly going to change somehow-- rather it means that
the same innovation that has been happening, is continuing to happen.

We were just talking about moving the language forward and deprecation
and whatnot a couple weeks ago (for months really, I reckon). There are
blogs where people say they only use createObject for Java now, and use
new everywhere else. Micha's suggestions and contributions make perfect
sense in that context.

Is deprecating createObject really a "show stopper"? I personally don't
see how it could be, but I'm willing to be shown how it is. And I
didn't think the createObject("blah",{}) was horrible or something, but
even if that were to happen, I'd still deprecate it, for the very
reasons Micha (and lots of other people across the interwebs) have
noted: There are "newer" ways to do it, and *using createObject is
potentially dangerous*. It is a perfect candidate.

-Den

[Geoff Bowers]

On Monday, 20 April 2015 08:46:26 UTC+10, Sean Corfield wrote:

Lucee is forcing me to write code that depends on deprecated features in order to run that code unchanged on multiple engines. That is a bad thing.

Assuming for a moment that we all agree the arguments for “createComponent() et al” (or whatever the family of functions ends up being called) are valid, and the addition of these functions has value...

How do you believe LAS should handle something like this “createObject()” scenario?

If LAS should not be using the term “deprecate”, what term should LAS be using to indicate that better alternatives exist in the Lucee Server implementation?

GB

 

[Steven Durette]

How about instead of using deprecated using CFML and LUCEE designations. While I understand, and rightfully so, that in many cases some people don't follow the idea that deprecated means to be removed, some management types that do make the final decision on what we can use do follow the standards that Microsoft and others (Google/apple/etc) set. Trying to fight that with "that's not what they meant" doesn't usually work. I was able to get a Railo server approved at work (before Lucee) and they did check for things like deprecated items to ensure that our existing code base wouldn't need an entire re-write.

Also stating that one way is better than another, without any stats (less memory usage, faster processing) is just a personal preference. Put 10 different programmers on a problem and you will likely get 10 different answers. If there is no difference in the end result (including resources) then they are all valid and a personal choice. Saying something is deprecated without those stats is the same thing as telling me I'm wrong because I don't think like you. 

At least saying something like this is the Lucee way and that was the CFML way works better and it also allows for room to adjust if the two languages converge or diverge further. 

These are my opinions and I hope I am presenting them professionally. If any offense is taken that was not my intent. 

Thanks

Steve 

Sent from my iPhone

--

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/1ed04aa3-a54e-4251-87f4-be3a2e153d2e%40googlegroups.com.

[Sean Corfield]

Stop muddying the waters with such weasel wording.

Deprecation has a common meaning — and you are trying to bend that to your will to avoid the point being made here. I can see why Adam has gotten so angry when trying to get a straight answer out of the Lucee team.

[Andrew Penhorwood]

Deprecation has a common meaning — and you are trying to bend that to your will to avoid the point being made here. I can see why Adam has gotten so angry when trying to get a straight answer out of the Lucee team.

Who cares if the function is deprecated?  It only becomes a problem if the function is removed.  Last time I checked none of us were paying Micha to write a CFML engine for us.  We are all using his work for free but feel entitled to complain that he doesn't follow our rules.

Andrew Penhorwood

[denstar]

I didn't want to have to bust the link-to-the-definition type deal, but what the hey:

http://docs.oracle.com/javase/7/docs/api/java/lang/Deprecated.html

https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html

I think createObject fits the bill.  Deprecated does not mean incompatible.  How would deprecating something - just deprecating, not removing - break existing code?

What is the point you are trying to make?  I'm not being obtuse on purpose, it seems like createObject needs to be deprecated, and that the reasons thus far for not doing so are weak.  I'm surprised you do not agree- only sometimes calling init() "smells" good to you?

Plenty of answers have been given, they've been strait, and polite.  It's OK not to agree on things - it's *good* to have different views, even, to prevent "group think".  Expressing them constructively is just more efficient is all.

-Den

--
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/292B940D-719E-412E-8FD5-C453CF76A4FB%40corfield.org.

[Geoff Bowers]

On Monday, 20 April 2015 13:11:11 UTC+10, Sean Corfield wrote:

Stop muddying the waters with such weasel wording.

It's a pretty straightforward request for how you would prefer LAS to treat scenarios like this.  I'm trying to find common ground -- if you don't think an element can be deprecated how do you define it as being preferred?

 

Deprecation has a common meaning — and you are trying to bend that to your will to avoid the point being made here.

The common meaning as I understand it, with respect to Java is this:

"A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. Compilers warn when a deprecated program element is used or overridden in non-deprecated code."
Java 8 Docs: http://docs.oracle.com/javase/8/docs/api/java/lang/Deprecated.html

It's been this way since v1.5.

There is no specific reason to believe a deprecated element will be removed.  And especially if the emphatic statement of the project is not to remove such an element. 

All that should be needed is a clear statement from LAS as to how they define "deprecated", clarity on why something is flagged as deprecated, and a commitment to always consider CFML compatibility with anything that is does.

GB

 

[Kai Koenig]

> There is no specific reason to believe a deprecated element will be removed. And especially if the emphatic statement of the project is not to remove such an element.
>
> All that should be needed is a clear statement from LAS as to how they define "deprecated", clarity on why something is flagged as deprecated, and a commitment to always consider CFML compatibility with anything that is does.

I think the latter is one of the core problems in this discussion - that is in addition to lack of clear communication and direction from LAS and where there is communication it’s confusing at best. I understand there’s work going on to improve this and I hope seriously that this will make a difference in technical direction and stewardship and provide some overall direction, which I feel is currently not there.



Back to the problem at hand:

“Deprecated" as defined by the Java community is slightly open to interpretation - it doesn’t _necessarily_ mean it’s going to be removed, but it might as well be at some point.

Look at this example:

"It is recommended that programs be modified to eliminate the use of deprecated APIs, though there are no current plans to remove such APIs – with the exception of JVMDI and JVMPI – entirely from the system.” (emphasis on _current plans_).

Or: "So, currently it’s ok - but we might rip it out at some point anyway.”… :)



Sean’s, Adam’s - and in some points my - concerns are:


*** If LAS’ version of “deprecated” has an undefined or what I’d like to call “the common understanding” meaning, then it can at any point in time remove deprecated functionality for any reason.

Now: in a lot of cases that’s not a bad thing. Take for instance ParamExists(). The only places where this is being used would be _really_ old ACF code from the pre-CF6 days.

In cases like CreateObject (which is a core feature of today’s CFML development) it’s different.

1. If this _was_ removed, there’d be serious portability issues of frameworks and libraries across Lucee and ACF. And in case anyone needs a reality check: Railo/Lucee is currently a rather small sub-community of CFML users which itself is a small community. Language modernisation and everything is fine, but if one would be writing a framework or library, I’d predict they’d go for the wider reach first if there was a serious incompatibility in a core functionality like, well, creating objects.

2. Even if it was _never_ removed, there’d be a serious perception/communication issue: Again, if I put myself into the shoes of a framework or library author and I’d have to build a library on a feature that’s marked deprecated in one of the servers, that’d be at least weird. I might just write it targeting ACF or Lucee then. Or maybe not care that much about one of them. You might now argue: What do we care - refer back to step one and my reality check comment.


**** If LAS’ version of “deprecated” was defined as “we don’t want you to use this anymore, but we’ll keep it in the language anyway and will never remove it”, that’ll solve my point 1 from above, but it doesn’t target point 2.


How do we solve this though? After my two points above you can now clearly argue that Lucee might as well never be able to “deprecate” anything that makes it on paper or in practice incompatible with ACF. I don’t rally have a good answer for this question (yet). To me it comes down to establishing a process. Just defining what “deprecated” means for LAS is not enough. It has to be defined how deprecation of something can be proposed, let it be from LAS members or anyone from the wider community. Then the case has to be considered and implications need to be looked at and potentially resolved. Then there has to be a public and transparent vote where a to-be-defined group of people makes a binding decision that then gets executed and everyone goes behind it.

Currently clearly there isn’t any of those things and it comes down to someone having an idea, implementing it and putting it out there for alpha/beta release. That’s been working quite well to ok in a lot of cases in the past, but if LAS is serious in being a transparent open-source organisation I think the next steps have to be to move away from the current ad-hoc model of changing the language.

Cheers
Kai

[corfield.org]

That's about deprecating APIs in libraries, not language features. Kai's post says what I would have in response to this. 

Sean Corfield -- (904) 302-SEAN

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

World Singles, LLC -- http://worldsingles.com/

(sent from my iPhone)

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAOe-Q13p1w6jeTZrMBG%2ByB_XcPCZRq%3Dcr%3D-A%3DOB6X0VqYxNYqw%40mail.gmail.com.

[Daniel Jansen]

My ability and level of understanding of CFML (and programming in general) is nowhere near the level of anyone who what commented on this post.

I have been following this Google Group pretty much from day one and make an attempt to at least read every post.

My understanding of how Lucee was to be developed was to be the following:

• Cool new "stuff" was to be added both to the CFML dialect and to the new Lucee dialect.
  
• The CFML dialect would remain compatible with ACF and Railo.
  
• The new Lucee (.lucee) dialect was place where code was to be given a big house clean and that code that was considered no longer required would be depreciated to be eventually removed.
  

Please let me know if I have read in to this wrong?

So my take on this is that NO functions or tags should be depreciated from the CFML dialect - they should only be depreciated in the Lucee dialect.

So my suggestion would be clearly mark in the Docs CreateObject as ? Implemented (current status) in CFML dialect, Depreciated to be removed in version x in Lucee dialect.

The other thing is, and has been mentioned by others, the documentation in general is not usable in it's current state.

It's not linked from http://lucee.org, it's easy to miss on the Welcome to Lucee Wiki page (found under heading Reference) and has nothing about the dialects.

What has become very obvious is that the Lucee team NEEDs more resources - it simply doesn't have the man-power it sorely needs right NOW.

What is absolutely needed is a Project Manager to oversee what needs to be done to bring everything up to scratch and the community needs to be used (with clear direction from the Project Manager) to get a v1 of Lucee complete - code, documentation, website. You guys can not do it by yourselves and Micha cannot do everything.

The Lucee community WANTs to help - you need to task one of your very limited resources to spend all their time working on the Lucee project in that Project Manager's role.

Regards,

Daniel Jansen
Proprietor

Daniel Jansen Trading as Dan Services

ABN: 55 921 448 221

Mobile: 0402 427 828

Fax: 02 8569 0202

Email: dan...@danservices.com.au
Web: www.danservices.com.au

PO Box 1042

Batemans Bay 

NSW 2536

[denstar]

On 4/19/15 8:13 PM, Steven Durette wrote:
> How about instead of using deprecated using CFML and LUCEE designations.
> While I understand, and rightfully so, that in many cases some people
> don't follow the idea that deprecated means to be removed, some
> management types that do make the final decision on what we can use do
> follow the standards that Microsoft and others (Google/apple/etc) set.

http://stackoverflow.com/questions/8111774/deprecated-meaning

"deprecation may indicate that the feature will be removed in the
future." the "may" bit is key, I think.

We should educate management types, so they don't think it means
something that it doesn't.

A time and battle-tested route that works really well in my opinion is
to note the reason for deprecation, and if slated for removal, the
target version removal will occur.

If we do come up with our own term, I think we should follow that practice.

...

> Saying something is deprecated without those stats is the same thing as
> telling me I'm wrong because I don't think like you.
> At least saying something like this is the Lucee way and that was the
> CFML way works better and it also allows for room to adjust if the two
> languages converge or diverge further.

Stats are good. For the createObject issue specifically, my main
problem is that init() is not called, and although init() is kind of
"new" (in CF 9?), the fact is, it's here, and has been, and it should
mean what one would think it would mean.

> These are my opinions and I hope I am presenting them professionally. If
> any offense is taken that was not my intent.

I thought it was great! I don't mean to come off as some type of list
officer, policing things or something. It's a great list.

-Den

[denstar]

On 4/19/15 11:20 PM, Kai Koenig wrote:

> I think the latter is one of the core problems in this discussion -
> that is in addition to lack of clear communication and direction from
> LAS and where there is communication it’s confusing at best.

...

It's going to take forever to improve our communication if we think that
LAS, which is only a piece of it, is the only place where it can be
improved-- or even the main focus.

It is all in our hands-- more than it ever was with Railo. We are the
only thing holding us back. We could just, ya know, do it. Get 'er
done. Make it so.
Really, we could. Nothing is stopping us. Maybe nothing is? Maybe we
are! OH MY! What if things are really amazingly freaking awesome,
RIGHT NOW!?!? =)

It's odd how impressionable we are. (Is it unethical to use this
malleability for our own ends, even if these ends are "good"? Marketers
and politicians use it all the time...)

...

>
> Currently clearly there isn’t any of those things and it comes down
> to someone having an idea, implementing it and putting it out there
> for alpha/beta release. That’s been working quite well to ok in a lot
> of cases in the past, but if LAS is serious in being a transparent
> open-source organisation I think the next steps have to be to move
> away from the current ad-hoc model of changing the language.

Saying something is so, doesn't really make it so. (Except it kind of
does, which is so /weird/.)

For example, in this specific case, it did not come down to someone
having an idea in a vacuum, implementing it, and putting it out there,
though it has been portrayed as such.

The stuff that we say needs to happen (and does), basically happened.

There was a proposal, discussion, it was all transparent, we had plenty
of time for input-- Micha picked the names, but he's open to reason, and
this is like, bleeding edge we're talking about anyway. The direction
is sound, if in need of refinement.

I think we all recognize that the process needs improvement, but it is
improving, and will continue to do so. I have faith, based on logic.
Hopefully everyone feels more confident now. =]p

-Den

[Dominic Watson]

There has been lot of useful and plenty of unacceptable argument over a few issues.

Firstly, the use of the word deprecated - the LAS understands this concern and will be making its intentions clear. There will never be any danger of these features being removed from Lucee unless Adobe removes them. The wording that will be used to describe these features will be pinned down shortly and communicated. Please let us not have any more discussion about the semantics of it (we are all in agreement that the communication has been far from perfect).

What is left of this discussion are disagreements on:

* Whether or not it is possible to achieve what the new CreateComponent() function achieves within CreateObject() without breaking compatibility

* Whether or not it is more desirable to add further permutations to CreateObject() vs adding separate, more singular purposed functions

* The naming of the new functions

These are all opinions, and each side of the argument has expressed plenty of valid arguments. Let us not underestimate the difficult in choosing 'the most desirable' route forward here, nor kid ourselves that there is a single *perfect* solution.

I'd like to suggest that people refrain from discussing this particular topic as all opinions have already been expressed well enough to be mulled over. LAS are preparing official communications around this subject which will absolutely be informed by everyone's input.

--
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/9ADB6C00-F460-4137-874F-F175D7200B99%40corfield.org.

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

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Brad Wood]

There's been a lot of talk about framework authors and createObject() being deprecated.  Sean is the only framework author who's weighed in, I believe.

I'll speak for ColdBox here.  We aim to support both the Adobe CF engine, Railo, and Lucee.  Lucee has announced that createObject() is not the best way to instantiate objects, but has also stated it will always remain in their CFML compatibility.  Therefore Coldbox will happily continue to use CreateObject() for the foreseeable future. That's it!  We're not worried at all since the intention has been clearly stated.

Thanks!

~Brad

[Nando Breiter]

On the issue of perception ...

As I have stated previously, I run my own business. It's bloody tough to make ends meet. I'm forced to make compromises all the time, simply to keep the bills paid. As a consequence, my output is far from perfect. Ideally, my code and coding practices could be much better, if only . Well, there's just not enough time in the day, and not enough money coming in to hire help. Even if someone walked in the door and volunteered to help for free, managing this person would take a significant amount of time, and that's a risk. Hence, I understand the tendency for small teams without capital to be backed into a corner that is difficult to work your way out of.

I have a lot of sympathy for the position the Lucee team is in. Financially, they are stretched thin, perhaps very thin. They each need to hustle to make a living doing something else besides Lucee development.  I personally think it's amazing that they continue to take on one of the largest corporations in the world, Adobe, and with only a tiny fraction of the capital, produce a CFML engine that is in many ways superior. With Lucee 5, they've completely revamped the codebase to be architecturally more sound than it ever has been. I won't attempt to restate the details, but from what I've read, the effort was significant, and is still ongoing.

Thank you. That's awesome. 

And of course, with the financial situation of LAS as it is, compromises are inevitable, and to me, perfectly understandable. In addition to the Lucee 5 rewrite, the team hit a "Who moved my cheese?" moment, and they've needed to seek out/develop other sources of income. I note, with admiration, that they did not throw up their hands and get cushy 9-5 jobs. They remained committed to their CFML project. To me, that's inspirational. Warts and all, I admire these guys for that.

One of the warts is of course documentation. It would help a lot if the effort was financed. I have no idea what a reasonable budget for this might be, but I'll throw a number out - $50,000. Explanatory text, really good examples, excellent user interface, complete and comprehensive. There's over a thousand tags and functions. That's about $50 each. That's a good chunk of money, but if everyone on this list chipped in $100, we'd have it raised. Doable if we pull together.

Sometimes, as a group of programmers, we get too focused on small details. Sure, they are important. But if we lose sight of the bigger picture in the process, I think we lose our way. 

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
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/5534BF6B.6040901%40gmail.com.

[Dominic Watson]

Adam, please stop this. That documentation is fundamental is well understood and steps are being taken to get both process and documentation in place. This can not happen overnight however, and continually harassing a single person in public will not help (Micha alone can not do this).

If you really must take issue with Micha in this way, please do so in private.

--

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/8802cfbe-f088-4170-aa13-0cc97adb2710%40googlegroups.com.

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

[Tom King]

I can probably weigh in for cfWheels here - we intend to support ACF/Railo/Lucee. Our next release has Lucee support (which, being so closely tied to Railo, was a matter of about 5 code changes as it stands), but obviously due to cross platform needs, I can't see how how the framework could use ".lucee" without a major fork, so the backwards compatibility thing is still a big deal.

[Sean Corfield]

Since FW/1 supported Lucee _at launch_ it should go without saying that FW/1 will continue to support Lucee (at least as a CFML engine — providing a Lucee-dialect-only version of FW/1, optimized specifically for Lucee, is an interesting option).

Like any other library or framework that has a single cross-platform code base, FW/1 and DI/1 will continue to use createObject() — and will continue to deliberately construct uninitialized instances where they need to do so — and it will continue to pain me that, as part of that commitment to portability, I have to use a feature that one engine has deprecated… :)

Sean

[Daniel Jansen]

I think this is where a lot of the frustration is coming from - communication (or rather incomplete communication).

If the Lucee Asso. needs some cash to get the docs done TELL us, I know that I would be willing to put in $100 to help get this sorted and I'm sure I'm not alone.

Everyone recognises that the resources of the Lucee Asso. are limited - what we all keep asking is what can we do to help? 

If the Lucee Asso. needs to raise enough funds to cover a resource to act as the overall project manager so that the available resources in the community can be effectively utilised - DO IT. Tell us how much we need and lets see if we can raise the cash?

I mean if an ides for a bee hive (Aussie invention) that can be harvested without disturbing the bees can raise millions, surely we could find a way to fund this?

Final thoughts,

I love not having to bend over for Adobe all thanks to the Railo, now Lucee community - I don't want that to go away.

I really appreciate the work and effort that goes into Lucee and want to thank all involved.

Regards,

Daniel Jansen
Proprietor

Daniel Jansen Trading as Dan Services

Daniel Jansen Trading as Web Design Batemans Bay

ABN: 55 921 448 221

Mobile: 0402 427 828

Fax: 02 8569 0202

Email: dan...@danservices.com.au
Web: www.danservices.com.au

Web: www.wdbb.com.au

PO Box 1042

Batemans Bay 

NSW 2536

[Adam Cameron]

On Monday, 20 April 2015 20:17:20 UTC+1, Dominic Watson wrote:

Adam, please stop this. That documentation is fundamental is well understood and steps are being taken to get both process and documentation in place. This can not happen overnight however, and continually harassing a single person in public will not help (Micha alone can not do this).

If you really must take issue with Micha in this way, please do so in private.

I'm having issue with the project, Dom, and the way it's managed & presented. There is a specific problem with the way the beta has been presented with inadequate docs. What I was trying to point out that saying Lucee is short-personnelled is not the issue here, it's the approach that needs work, in that the docs need to be done @ the same time as the coding, because it's part of the deliverable. It still doesn't seem to be being dealt with with the beta docs, and the excuse of being short-personnelled is still being used. I think it's not a matter of more work, it's a matter of different work, and a different attitude to the work in future.

Perhaps that's understood. But if it is, that's not being articulated.

-- 

Adam

[Alex Skinner]

Adam,

As Dom has said there has been a huge amount of work in the last few weeks be it behind closed doors to sort out the docs, not just the actual result but the whole process, build and review.

I agree that elements have been released too early and the documentation has been substandard.

My surprise is that people see this as something that has happened since Lucee, the docs in my mind have been lacking for some time, even Mark tried to solve the problem retrospectively with Railo. We need to do better on docs this is clear and is complete understood

I don't share your review that the process should be more transparent, it needs more people involved definitely. But too much transparency at too early stages will just start protracted discussions all over the place and things moving to a crawl.

Structure to support Micha while allowing others to help in a meaningful way is top priority

Watch this space

Alex

--

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/dc95a52d-3dd1-4486-babb-e46effcebcf8%40googlegroups.com.

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

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

[Michael Offner]

Hi Daniel 

That is what the supporter program is about

http://lucee.org/get-involved.html

We try to get the project covered with help of our supporters, but of course we are not there yet.

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/e9eeaaa0-20f3-4040-8969-04a80b6c05f1%40googlegroups.com.

[Adam Cameron]

Cheers mate that all sounds very promising.

Obviously Lucee needs good docs, and sounds like we've got good champions there getting the site up and running, and hopefully bods like me can easily contribute to it once it's available.

My main concern in this documentation "discussion" at the moment is the beta docs more than the "proper" docs. But I think the message has been articulated there, so only mention this by way of clarification.

I look fwd to the launch of the work you guys are plugging away at.

-- 

Adam

[Adam Cameron]

On Monday, 20 April 2015 17:55:44 UTC+1, Nando Breiter wrote:

 

Good stuff, Nando. I've only snipped it out as I have nothing to say beyond that. This bit though:

 

One of the warts is of course documentation. It would help a lot if the effort was financed. I have no idea what a reasonable budget for this might be, but I'll throw a number out - $50,000. Explanatory text, really good examples, excellent user interface, complete and comprehensive. There's over a thousand tags and functions. That's about $50 each. That's a good chunk of money, but if everyone on this list chipped in $100, we'd have it raised. Doable if we pull together.

I'm not gonna contest any of that, but bear in mind if the docs are maintainable by the hoi polloi, it doesn't need to be $50k's worth of perfect all-encompassing solution to start with. If you give me a page and some initially auto-generated content and a template for how to format examples and what not, I'll go in there and chip away at it for free. As will other people as the need arises.

So all they need to release is "good enough" as a first iteration, and then let the community help, and perhaps each week (or something) put a few hours of the LAS Team's time in back-filling and polishing.

And I already discussed elsewhere an approach to making sure any docs for new functionality is also iteratively developed by both LAS Team and community together.

It doesn't need to be a monster.

But from what Alex and Dom say it's all in hand, so we shall see what we shall see....

-- 

Adam 

[Nando Breiter]

Adam,

Whether or not it is done "for free", I still see that there are in the range of 1000 items of documentation to complete, for functions, tags and objects/member functions. Developing good examples and writing a description for some of these, like the cfset tag, will be quick. Others might easily take more than an hour.

So give or take, let's call it 1000 hours of work. I'm assuming, like other technical writing, it will all need to be gone over more than once. If you can spare 10 hours a week, it'll take you 2 years. If I'm overestimating by half, it'll take you a year. Will you get fed up after a few weeks or months? Have other priorities arise? I think that's likely enough that it should be anticipated.

Those are the sort of thoughts that are running through my mind when I think that maybe the project deserves a budget. 

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--

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/bfdedd1b-1977-4450-812b-fdd3c2b70c08%40googlegroups.com.

[Adam Cameron]

On Tuesday, 21 April 2015 20:23:27 UTC+1, Nando Breiter wrote:

Adam,

Whether or not it is done "for free", I still see that there are in the range of 1000 items of documentation to complete, for functions, tags and objects/member functions. Developing good examples and writing a description for some of these, like the cfset tag, will be quick. Others might easily take more than an hour.

So give or take, let's call it 1000 hours of work. I'm assuming, like other technical writing, it will all need to be gone over more than once. If you can spare 10 hours a week, it'll take you 2 years. If I'm overestimating by half, it'll take you a year. Will you get fed up after a few weeks or months? Have other priorities arise? I think that's likely enough that it should be anticipated.

Those are the sort of thoughts that are running through my mind when I think that maybe the project deserves a budget. 

Or we could think smart. the CF9 docs are CC licensed, and there is a phenomenal overlap with Lucee there. That work has been done and Adobe are happy for the gen. pop. to use 'em. Their narrative and examples aren't great in a lot of areas, but they're still better than what Lucee currently has. I've converted it all to subsectioned (eg: spec, history, description, etc) JSON, which would make it bloody easy to initially import.

You're only estimating for one person in that two years, and there's no reason to think there'll only be one person doing it.

And there's an element of "if a tree falls over in a forest" here. There's a bunch of stuff which no-one's gonna care about, so until someone actually raises it, there's no need to document it. And at any rate... the automated stuff that Mark has done is at least a half-decent start there.

It might take two years to complete. But applying the 80/20 sort of notion, it'd be the sort of thing that could get to 80% pretty quickly.

I'm not trivialising the undertaking or your point, but like eating elephants... the individual bite sizes aren't that big or daunting.

-- 

Adam

[Kai Koenig]

Or we could think smart. the CF9 docs are CC licensed, and there is a phenomenal overlap with Lucee there. That work has been done and Adobe are happy for the gen. pop. to use 'em. Their narrative and examples aren't great in a lot of areas, but they're still better than what Lucee currently has. I've converted it all to subsectioned (eg: spec, history, description, etc) JSON, which would make it bloody easy to initially import.

CF 10 docs are as well, CC 3 - by-nc-sa, which shouldn’t be an issue as long as LAS is happy to attribute Adobe license-compliant.

Cheers

Kai

[Adam Cameron]

On Tuesday, 21 April 2015 21:00:42 UTC+1, Kai Koenig wrote:

CF 10 docs are as well, CC 3 - by-nc-sa, which shouldn’t be an issue as long as LAS is happy to attribute Adobe license-compliant.

Oh so they are! Cool. Good ole Adobe.

-- 

Adam 

[Judith Barnett]

My suggestion would be for whomever tackles that that they start with the hard and the new stuff.  The simple tags most of us know how to use, or could contribute simple explanations in very short period of time.  I am building a database of all tags and functions, with indicators of differences, so I can support all the various versions of CFML I support

I am currently traveling cross country not able to do much work on it, but at some point will make it publicly available with the ability for corrections and additions.  Probably won't happen before mid-summer however.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D8DW-_cTeniteGVp3cpp5GWHHyWRHz9HzVywzXxC1666w%40mail.gmail.com.