remove element from Array still returns boolean without javacast

[Mattijs Spierings]

Hi,

Referring to the issue logged here:

https://issues.jboss.org/browse/RAILO-1809

var drawindex = RandRange( 1, seedGroup.len() );

                var winner = seedGroup.remove( javaCast( 'int',drawIndex ) );

`seedGroup` is an array, with just numbers. I am running this in a loop of course.

If I do not use javaCast, the array remove() function (which is not in the docs by the way...?!?), the result is a boolean False.

With the javacast, it returns the number that was removed from the array and they seedGroup array has been reduced by one element.

Is this something that is going to be amended?

[Mattijs Spierings]

Oh, and how annoying: using the underlying Java functions means it assumes that the array starts at 0 and not Coldfusions (annoying 1).

Is it an idea to ADD a remove function to Lucee? Pretty basic requirement IMO

[Adam Cameron]

On Tuesday, 17 November 2015 02:14:50 UTC, Mattijs Spierings wrote:

If I do not use javaCast, the array remove() function (which is not in the docs by the way...?!?),

Except for here:

https://docs.oracle.com/javase/8/docs/api/java/util/AbstractCollection.html#remove-java.lang.Object-

And here:

https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#remove-int-

 

the result is a boolean False.

With the javacast, it returns the number that was removed from the array and they seedGroup array has been reduced by one element.

Is this something that is going to be amended?

What do you perceive needs amending here? You're calling methods on the underlying Java implementation of Lucee's "array", which inherits from java.util.AbstractList and in turn java.util.AbstractCollection.

It's ubiquitous knowledge (innit?) that Lucee object implementations are extensions of underlying Java classes, so if you're calling an "undocumented" method, then it's likely to be one of the underlying Java methods. Only if it's not a method of the underlying Java implementation would a method be "undocumented".

That said, there's a discussion to be had (and perhaps a separate one) as to whether calling Java methods as opposed to "member functions" is, strictly speaking, "supported": it's implementation detail that lucee.runtime.type.ArrayImpl ultimately extends java.util.AbstractList (etc), and indeed it's even implementation detail that lucee.runtime.type.ArrayImpl is "a thing" in the first place. It's unclear whether it's a defined "contract" that this level of implementation is intended to be understood by CFML developers/code, and therefore whether one ought to be using methods like remove() in the first place. It could be legit (if unlikely) that Lucee decides to shift away from java.util.AbstractList, in which event your code will stop working.

Perhaps what needs to happen is for the Lucee Docs project to be augmented to have placeholder pages for things like scopes, types, etc, so people can document them, including what the level of officially sanctioned usage is. It might be worth you raising a Jira ticket to get this implemented, if you think it's a shortcoming.

[Mattijs Spierings]

I would say that we must assume the Lucee / CFML developer does NOT have knowledge of underlying JAVA functions. Like you say, they are not supported/documented and can contradict or conflict with Lucee's implementation or train of thought. Like me calling a JAVA delete function and then complaining about the `array start from 0 or 1 ` thingy.

I could only advocate that we make sure that all the basic functions for struct and array (and more) editing are in place there so that nobody has to go the the underlying JAVA layer. Me calling a Java delete function is only because I couldn't find a SPLICE function in the docs. There might be ways around this, but I am used to Javascript and doing it these things in one line ( not a long line though :P ).

Maybe we can start a list of functions that people like to see implemented, I think we are already way on track but there are always a couple of things we don't want to do in a UDF.

About they Jira ticket, I am not sure how high of a priority that would be. I heard the dev team right now is pretty swamped. Can't we already edit the docs? I can propose a change when I click on the little pencil and edit on github

[Mattijs Spierings]

the thing to be amended was to remove the javacast, but I see now that if this is a native Java function, Lucee has no control over this unless it is a lucee facade function that directly calls java's delete

On Tuesday, 17 November 2015 19:18:26 UTC+11, Adam Cameron wrote:

[Michael Offner]

You can disable "direct Java invocation" in the server admin security page. This way calling underlaying methods is blocked.
If you miss a functionality in cfml and you have to relay on the Java layer, let us know in a Jira ticket (bug.lucee.org) we will review.

Micha

--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/d6800b6b-1d1c-4cb5-948a-a6fdc18484bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Offner]

You can disable "direct Java invocation" in the server admin security page. This way calling underlaying methods is blocked.
If you miss a functionality in cfml and you have to relay on the Java layer, let us know in a Jira ticket (bug.lucee.org) we will review.

Micha
Am Mittwoch, 18. November 2015 schrieb Mattijs Spierings :

[Mattijs Spierings]

Roger!

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.