Is there any way to avoid redundant sys::Depend in a pod? Because it looks too hard for understanding: @podDepends = [Depend("sys 1.0"), Depend("gfx 1.0"), Depend("fand 1.0"), Depend("web 1.0"), Depend("webapp 1.0"), Depend("wisp 1.0"), Depend("compiler 1.0"), Depend("compilerJs 1.0")]
I believe it will be better to have something like @podDepends = Depends("sys 1.0, gfx 1.0, fand 1.0, web 1.0, webapp 1.0, wisp 1.0, compiler 1.0, compilerJs 1.0").toList
brianWed 23 Sep 2009
I don't really want to add a Depends class to sys - adding new classes to sys requires an extremely high bar.
Couple options:
make podDepends Str (one big free-form string)
make podDepends Str[] (considered this originally)
I settled on current design since it seems most inline with Fan's idioms for static typing as explicitly as possible. But I can see simplicity in using just Strings (same thing as using Uri vs File in build scripts).
I'd like to hear more feedback from others that they want to change things first though.
casperbangWed 23 Sep 2009
I don't really like free-form stuff buried in strings (that's how Java seems to be evolving these days). Is it out of the question to introduce a simplified vararg feature?
Varargs would be nice - I just don't want to tackle for 1.0 since I believe they will have complex interactions with closures, dynamic calls, etc.
In this case, I believe the heart of the issue is that podDepends is typed as a Depend[] (so I am not sure var args really help). If anything you'd want a shortcut for declaring a list of simple types:
Alternatively it could be Depend.fromList which could potentially be a compiler supported pattern similar to fromStr.
brianWed 23 Sep 2009
Having a Depend.fromListStr (or whatever it is called) would be a nice API (as opposed to language) way to handle it. Although at the same time, I am a bit worried about this particular use case because it needs to be parsed and understand by tools before a full compile - the way I am that today is a bit hackish and I don't want to make it more complex.
Yuri StrotWed 23 Sep 2009
I hope this wouldn't be a big problem, because Depend.fromListStr shows to good advantage.
Yuri Strot Wed 23 Sep 2009
Is there any way to avoid redundant
sys::Depend
in a pod? Because it looks too hard for understanding:@podDepends = [Depend("sys 1.0"), Depend("gfx 1.0"), Depend("fand 1.0"), Depend("web 1.0"), Depend("webapp 1.0"), Depend("wisp 1.0"), Depend("compiler 1.0"), Depend("compilerJs 1.0")]
I believe it will be better to have something like
@podDepends = Depends("sys 1.0, gfx 1.0, fand 1.0, web 1.0, webapp 1.0, wisp 1.0, compiler 1.0, compilerJs 1.0").toList
brian Wed 23 Sep 2009
I don't really want to add a Depends class to sys - adding new classes to sys requires an extremely high bar.
Couple options:
I settled on current design since it seems most inline with Fan's idioms for static typing as explicitly as possible. But I can see simplicity in using just Strings (same thing as using Uri vs File in build scripts).
I'd like to hear more feedback from others that they want to change things first though.
casperbang Wed 23 Sep 2009
I don't really like free-form stuff buried in strings (that's how Java seems to be evolving these days). Is it out of the question to introduce a simplified vararg feature?
@podDepends = Depend(["sys 1.0", "gfx 1.0", "fand 1.0", "web 1.0", "webapp 1.0", "wisp 1.0", "compiler 1.0", "compilerJs 1.0"])
I've been needing that a few times now http://fandev.org/sidewalk/topic/738#c5164.
brian Wed 23 Sep 2009
Varargs would be nice - I just don't want to tackle for 1.0 since I believe they will have complex interactions with closures, dynamic calls, etc.
In this case, I believe the heart of the issue is that podDepends is typed as a
Depend[]
(so I am not sure var args really help). If anything you'd want a shortcut for declaring a list of simple types:andy Wed 23 Sep 2009
Using
fromStr
as a convenience for lists is an interesting idea.qualidafial Wed 23 Sep 2009
Alternatively it could be
Depend.fromList
which could potentially be a compiler supported pattern similar tofromStr
.brian Wed 23 Sep 2009
Having a Depend.fromListStr (or whatever it is called) would be a nice API (as opposed to language) way to handle it. Although at the same time, I am a bit worried about this particular use case because it needs to be parsed and understand by tools before a full compile - the way I am that today is a bit hackish and I don't want to make it more complex.
Yuri Strot Wed 23 Sep 2009
I hope this wouldn't be a big problem, because Depend.fromListStr shows to good advantage.