pantsbuild #development

Channels

welcome

github-notifications

development

witty-crayon-22786

11/09/2015, 12:45 AM

@enough-analyst-54434: my first thought was that something like 'requires' would allow for composition of configs, rather than the existing 'extends', ie inheritance

witty-crayon-22786

11/09/2015, 12:46 AM

such that rather than having one merged config object, you must have two

enough-analyst-54434

11/09/2015, 12:46 AM

Its not clear to me how abstract,extends,merges has much to do with the problem

witty-crayon-22786

11/09/2015, 12:47 AM

might still be something there... but the 'required' composition can't be defined on the config itself.

enough-analyst-54434

11/09/2015, 12:47 AM

Those just allow writing a given single config way with clean re-use

enough-analyst-54434

11/09/2015, 12:47 AM

Well, there is the validation hook

enough-analyst-54434

11/09/2015, 12:47 AM

It is intended for verifying all fields are filled in with suitable values

witty-crayon-22786

11/09/2015, 12:48 AM

right... using it for composition rather than "inheritance" would mean validating that some other config is present as well.

enough-analyst-54434

11/09/2015, 12:49 AM

I'm still not seeing how this helps decide whether to blow up - at the end of the day the config has the needed fields or it doesn't. Whether those fields are all merged or embedded seems not to affect the blowup

enough-analyst-54434

11/09/2015, 12:49 AM

Just cleanliness

witty-crayon-22786

11/09/2015, 12:50 AM

yes

enough-analyst-54434

11/09/2015, 12:50 AM

k - I'm not too concerned with that - that's the easy part afaict

witty-crayon-22786

11/09/2015, 12:50 AM

ok, will think about it some more. sidenote: what is the usecase for extends vs merges?

enough-analyst-54434

11/09/2015, 12:51 AM

extends overlays, merges appends containers

enough-analyst-54434

11/09/2015, 12:51 AM

extends wipes-out, merges adds to dicts and lists

witty-crayon-22786

11/09/2015, 12:51 AM

yea... but i'm wondering if

extends

is actually a good idea.

enough-analyst-54434

11/09/2015, 12:51 AM

May be we could collapse, I'm all for simpler

witty-crayon-22786

11/09/2015, 12:52 AM

(again, the composition vs inheritance thing)

witty-crayon-22786

11/09/2015, 12:52 AM

not overriding concrete fields is good best practice anyway

enough-analyst-54434

11/09/2015, 12:52 AM

These are just structs, no behavior

enough-analyst-54434

11/09/2015, 12:52 AM

So its not clear to me that typical inheritance / comp concerns are the same

enough-analyst-54434

11/09/2015, 12:53 AM

But, although an important choice to make and get right, I don;t think this is material to the hard problem you're working on

witty-crayon-22786

11/09/2015, 12:53 AM

i suspect they are, but yea. just thinking that if there isn't a usecase for extends yet, could kill it

witty-crayon-22786

11/09/2015, 12:53 AM

nope: definitely a sidenote

witty-crayon-22786

11/09/2015, 12:53 AM

ok, thanks!

witty-crayon-22786

11/09/2015, 1:27 AM

@enough-analyst-54434: another quick idea, just to decide whether it is worth prototyping

witty-crayon-22786

11/09/2015, 1:28 AM

Planners could optionally declare that the product they produce falls into a particular category, ie

Sources.of('.java'):thrift

witty-crayon-22786

11/09/2015, 1:30 AM

if no Planners were able to produce a Promise for a particular category of a product (ie, ApacheThriftPlanner and ScroogePlanner both declare

Sources.of('.java'):thrift

but neither produce a promise for it), then it is an error

witty-crayon-22786

11/09/2015, 1:31 AM

how to make it a good error is likely the next thing to think about.

witty-crayon-22786

11/09/2015, 1:47 AM

mmm, perhaps the category is actually the input that was consumed to produce the product