RFC: arbitrary transformation for renderables

[Dustin J. Mitchell]

Indeed, that's what I'm thinking of and it is quite unlikely.

Dustin

On Sun, Oct 4, 2015 at 10:28 AM, Роман Донченко <dpb at corrigendum.ru> wrote:

> Alright, I'll start working on the merge request, then.
>
> I don't see how a cycle is possible here, BTW. (Unless you mess with a
> Transform object after it's been created, which is definitely user error.)
>
> Dustin J. Mitchell <dustin at v.igoro.us> писал в своём письме Sun, 04 Oct
> 2015 17:23:40 +0300:
>
> Ah, I see that the distinction is deeper than just allowing asynchronous
>> returns -- Transform works on other renderables, whereas renderer creates
>> new renderables (which take the build `b` as an argument).
>>
>> I like that this allows multiple renderables as input - nice design!
>>
>> There's a risk of circular dependencies, but I think we can consider that
>> "user error" and not do anything to try to prevent it (cycle detection
>> would be pretty hard here!).
>>
>> So yes, I think this would be a good addition to the property support.
>>
>> Dustin
>>
>> On Sun, Oct 4, 2015 at 10:12 AM, Роман Донченко <dpb at corrigendum.ru>
>> wrote:
>>
>> I don't see how that would work.
>>>
>>> IMO, renderer and Transform are very different things. The former creates
>>> a new renderable based on a user-defined function; the latter combines
>>> existing renderables based on a user-defined transformation. They can't
>>> (and shouldn't) be implemented by the same function.
>>>
>>> Dustin J. Mitchell <dustin at v.igoro.us> писал в своём письме Sun, 04 Oct
>>> 2015 16:55:46 +0300:
>>>
>>>
>>> Could you possibly extend renderer to handle that case?
>>>
>>>>
>>>> Dustin
>>>>
>>>> On Fri, Oct 2, 2015 at 4:17 PM, Роман Донченко <dpb at corrigendum.ru>
>>>> wrote:
>>>>
>>>> Pierre Tardy <tardyp at gmail.com> писал в своём письме Fri, 02 Oct 2015
>>>>
>>>>> 00:25:36 +0300:
>>>>>
>>>>> Hi Roman,
>>>>>
>>>>>
>>>>>> There is already a renderer function which is similar simplification
>>>>>> of
>>>>>> the
>>>>>> renderable pattern.
>>>>>> You can do
>>>>>>
>>>>>> renderer(lambda _: datetime.date.today().isoformat()
>>>>>> renderer(lambda b: os.path.relpath(p.getProperty('buildir'))
>>>>>>
>>>>>> The latter is a little bit more chars than your solution, but probably
>>>>>> more
>>>>>> easy to follow.
>>>>>>
>>>>>>
>>>>>> I know this, but it doesn't work when the arguments are arbitrary
>>>>> renderables (since you have to account for the possibility that they
>>>>> return
>>>>> a Deferred). The brevity is nice to have, too.
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at buildbot.net
>>>>> https://lists.buildbot.net/mailman/listinfo/devel
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/devel/attachments/20151004/c1deb10e/attachment.html>