Remove element from Array still returns boolean without javacast

dev google-group-archive
#1

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?

#2

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.On Tuesday, 17 November 2015 02:14:50 UTC, Mattijs Spierings wrote:

#3

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
IMOOn Tuesday, 17 November 2015 13:14:50 UTC+11, Mattijs Spierings wrote:

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?

#4

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 :stuck_out_tongue: ).
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
githubOn Tuesday, 17 November 2015 19:18:26 UTC+11, Adam Cameron wrote:

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.

#5

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 deleteOn Tuesday, 17 November 2015 19:18:26 UTC+11, Adam Cameron wrote:

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.

#6

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.

MichaAm Mittwoch, 18. November 2015 schrieb 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:

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.

–
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/d6800b6b-1d1c-4cb5-948a-a6fdc18484bf%40googlegroups.com
https://groups.google.com/d/msgid/lucee/d6800b6b-1d1c-4cb5-948a-a6fdc18484bf%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

#7

Roger!On Thursday, 19 November 2015 18:05:39 UTC+11, Micha wrote:

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 :

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:

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.

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/d6800b6b-1d1c-4cb5-948a-a6fdc18484bf%40googlegroups.com
https://groups.google.com/d/msgid/lucee/d6800b6b-1d1c-4cb5-948a-a6fdc18484bf%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.