Standard Component/Class Library

I had already begun work as a side project on my own of developing what I’m calling the Standard Component (Class?) Library. It would be something along the lines of C++'s stdlib, or PHP’s Standard PHP Library. My thoughts are that it would be primarily some base interfaces/classes, but also could become an object-oriented “porcelain” (to borrow from Git) to current BIF capability.

I bring this up, as it is somewhat intrinsic to the reply I posted on the Rename the function JavaNew topic. I just want to throw it out there as possibly something I could turn over at some point to be a core language library (assuming something like this is not already in the works). I hope to have some code out on github soon.

Just by way of some examples:

import scl.Iterable;
import scl.Countable;

class NonIteratingIterable implements=Iterable,Countable {
    public boolean function hasNext() { return false; }
    public any     function next()    { return; }
    public any     function current() { return; }
    public numeric function length()  { return 0; }
}
import scl.query.Query;

resultSet = Query::execute("select * from someTable", [], {dataSource="mydsn"});

stmt = Query::prepare("select * from someTable where id = :id", "mydsn");
resultSet = stmt.execute({id: 1});

// resultset implements iterable
while(resultSet.hasNext()) {
    dump(resultSet.next());
}

// the query object is still available:
for (row in resultSet.getData()) {

}

// could even do Linq-type queries...
result = LinqQuery::from([
   {id: 1, firstName: 'Jesse', lastName:'Shaffer'}
]).select({
   fullName: '${firstName} ${lastName}'
});

// result now holds [{fullName:"Jesse Shaffer"}]
1 Like

Two things

  1. FWIW, a rough draft of what I’m thinking: http://github.org/dajester2013/Lucee-SCL
  2. I know there’s the org.lucee.cfml package that is autoimported, but the roadblocks for me there is that
    a) it seems to me that it is only used for the V1 of script tag support, so if you were to try to put the components directly into that package:
    b) there would be potentially incompatible changes - specifically to Query - that I don’t know would work well with the existing component. so I thought, you could put the scl package under the cfml package, but then
    c) according to my understanding you would have to do import org.lucee.cfml.scl.* instead of being able to do just import scl.*. Not that big of a deal, but it is redundant.

Why not extend the existing query component with this new functionality in a way that does not break backward compatibility?

There is nothing speaking against having a Iterator interface inside the auto import package.
Lucee is supporting a lot of different interfaces with cfloop-collection, this also includes the Java Iterator and Enumeration interface.
We could teach lucee to accept org.lucee.cfml.Iterator as interface for cfloop-collection.
I’m all for extending org.lucee.cfml maybe we should rename it to org.lucee.lang

That could be done - I liked the idea of separating the scl Query vs tag component Query, but with statics it is a non-issue.

As far as teaching the loops about the iterator interface, that would be awesome.

1 Like

As a side note, this can already be done with help of the function createDynamicProxy, not convenient but it works