On Mon, Apr 13, 2009 at 04:03:37PM -0700, Brock Pytlik wrote:
> Let's meet and talk this out (I just stopped by your office but missed
> you). I think we're having a fairly large miscommunication here :)
Ok, I'll stop by your office in a minute. I went to get some coffee and
when I came back jurassic was slow. I've caught it doing something
fairly naughty with nxge. Once I get that sorted, I'll be by.
>>>> - line 347: Is it possible to have a list that's not of type list?
>>>>
>>> Would you prefer arguments in place of list? I was trying to say, it
>>> takes lists, and more than that, it takes lists with a specific type.
>>>
>>
>> I really wasn't trying to be rhetorical here. I was trying to figure
>> out if you had imposed a specific type requirement on your lists -- by
>> subclassing maybe? However, it sounds like you were trying to explain
>> that the function expects a list with a pre-determined format of its
>> contents. If the latter is true, consider stating this in a way that
>> expresses that the lists must be in a format that the callee expects.
>> Perahps I'm being obtuse, or pedantic, but type implied class/instance
>> identity, which isn't what you mean.
>>
> Heh, didn't think you were being rhetorical. Types != class/instance for
> me at least. That's why I put the type signature to describe the type
> expected. You're right, it does expect lists that meet a certain
> type/format. I thought I was conveying that the function only accepts
> two lists of that type by saying that it takes two lists of a specific
> type. I'm open to suggestions on how to reword this bit but since I'm
> having trouble understanding the reading you took from it, I'm not
> exactly sure how to reword it.
> Is this clearer?
> """Takes two arguments. Each of the arguments must be lists with the
> type signature ('a, list of 'b).
This is clearer, thanks.
>>>> - line 458-460: I don't understand what this means. Can you explain
>>>> it a different way?
>>>>
>>> I can remove it, or I can have a fairly long explanation which would
>>> roughly be this:
>>> Restriction is only set by boolean queries, and currently only by AND
>>> queries. Further, if this node is returning packages, then the query
>>> containing it would also contain packages, and therefore not make
>>> use of restriction (hence it would be none). Therefore, the only way
>>> restriction is not None is when this query is contained within an
>>> AND query higher up in the AST tree.
>>>
>>
>> Since you've gone to the trouble of writing it here, there's no reason
>> why we couldn't modify the docstring. How about: (starting at 457)
>>
>> The variable 'restriction' is a generator of actions, over which
>> the search shall be performed. Only boolean queries will set
>> restriction. Queries that are returning packages do not set
>> restriction. Nodes that return packages have, by definition,
>> parents that must return packages. This means that only queries
>> contained within a boolean query higher up in the AST tree will
>> have restriction set.
>>
>> Or did I misunderstand how this works?
>>
>>
> Yep, that's right (modulo one nitpick). I wasn't sure that belonged in a
> docstring, but I'm happy to add it.
> Nitpick: queries which return packages could contain nodes which set
> restriction: <foo AND bar> is an example. This may change someday when
> query optimization gets worked in well.
Ok, great.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
