On Sun, Jul 5, 2020 at 4:19 PM Siegfried Goeschl < siegfried.goes...@gmail.com> wrote:
> See my comments inline ... > > > On 05.07.2020, at 15:25, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > > > See my comments inline... > > > > On Sun, Jul 5, 2020 at 2:49 PM Siegfried Goeschl < > > siegfried.goes...@gmail.com <mailto:siegfried.goes...@gmail.com>> wrote: > > > >> Hi Daniel, > >> > >> Please see my comments below > >> > >> Thanks in advance, > >> > >> Siegfried Goeschl > >> > >> > >> > >>> On 05.07.2020, at 13:42, Daniel Dekany <daniel.dek...@gmail.com> > wrote: > >>> > >>> The reason I was asking is that if all functionality goes in > >> DataSourcers, > >>> the methods will shadow data source names. Like if you have a data > source > >>> named "empty", then DataSources.empty will not return that, instead it > >> will > >>> call isEmpty(). That also means that adding new methods to DataSource > is > >>> not backward compatible. So probably we will need a separate > DataSources, > >>> and DataSourceTool or something. (It's also possible to reverse > >> priorities, > >>> but that's even less manageable for the user.) > >> > >> Thanks, I was not aware of that - let me recap my understanding > >> > >> If I have a data source "empty", e.g. "empty=somepath/some.csv" > >> > >> * DataSources.empty would call DataSources.isEmpty() > >> * DataSources["empty"] would fetch the data source "empty" > >> > > > > Yeah, so thing is, in FreeMarker, foo.bar and foo["bar"] are exactly the > > same. Furthermore, foo.bar() is just foo.bar, and then () operator is > > applied on it's value (which is a method as a first class value). > > > > > >> * DataSources.get("empty") would fetch the data source "empty" since it > >> calls DataSources.get(String) > >> > > > > Yes. > > > > > >> Some thoughts along the line > >> > >> * The names of a list of data sources are not enforced to be unique so > the > >> map functionality is slightly broken > >> > > > > Why not? That was also a quite important problem. I guess I even listed > it > > in the recent mail... or not. So these names and groups, should be > > consolidated too. > > Harvesting directory trees and consolidating the files into a single > output - here I can't guarantee that the names are unique > Why don't we just enforce the names to be unique? Then the map function won't be kind of broken either. But most importantly, user templates won't be, because when you care about the data source name, you (I mean the user) probably wan it to be unique, right? Like here, the intent is most certainly that "DataSources.accessLog" is not ambiguous in templates: -s accessLog=foo/access.log Yes, we also generate some "name" automatically, by taking part of an URL (like the file name part). Well, if someone is bothered by that (I would be), they can assign a name explicitly. But when files are collected by scanning a directory, then you are out of control, so at least then they shouldn't get a name by default. (The collected data sources still can have properties like file name, if someone cares, but then it's obvious that they aren't necessarily unique.) > > > > >> * Tools for me are stateless and can be potentially shared so I can not > >> put the data sources for the current transformation in there > >> > > > > I guess, technically speaking, you can. You are in the context of a > > freemarker-generator run (or whatever the term for that is... session?). > > Where's the ambiguity, or similar issue, if any? > > Still want to make the code embeddable so in my mental model the tools are > reusable and do not contain "session-specific" data > Some possible solutions: - Let's pass DataSources as an argument to the tool methods then. - Or, let's not call that thing a tool then, so it can know about the session. - Or DataSources should contain a collection of objects that has a matchedGlob method (among others), and then you can issue DataSources?filter(ds -> ds.matchesGlob('*.foo')). A bit verbose though. And bit indecisive maybe, as I guess the idea is that some stuff is just data, and methods that are not mere data access are in "tools". > > > [snip] > > > > -- > > Best regards, > > Daniel Dekany > > -- Best regards, Daniel Dekany
