hang on...  what does onlyleaves do?  when true should the results be a 
subset of the the results when it's false?  they are not, in the examples 
in the doc.  :o(

On Wednesday, 26 February 2014 19:25:06 UTC-3, andrew cooke wrote:
>
> this is great.  from just looking at the example in the docs i can see 
> i've missed a couple of methods!  thanks.
>
> On Wednesday, 26 February 2014 15:54:07 UTC-3, Leah Hanson wrote:
>>
>> The "% coverage" part is done. You can see the documentation at 
>> https://github.com/astrieanna/TypeCheck.jl#methodswithdescendantstdatatypeonlyleavesboolfalselimint10(anchor
>>  in the README). Please try it out and let me know whether it's 
>> helpful. (Note that abstract types are  included by default; using 
>> onlyleaves=true to get your requested behavior.)
>>
>> Usage statistics are definitely harder, but only because finding uses of 
>> a function in general is harder. I'll think about that a bit more; 
>> check_method_calls might have some of the needed infrastructure of that.
>>
>> Comparing types could be accomplished with a wrapper on the new 
>> methodswithdescendants function; I can add that.
>>
>> -- Leah
>>
>>
>> On Tue, Feb 25, 2014 at 4:26 PM, andrew cooke <and...@acooke.org> wrote:
>>
>>>
>>> sweet.  i'd like to see something like "% coverage". for Number, for 
>>> example, what % of concrete types have abs() defined?
>>>
>>> another useful statistic, which might not be possible, is across how 
>>> many modules is a function used - for example, which operation on Number 
>>> occurs in most modules?  which are used only in one module?
>>>
>>> it would also be nice if you could compare types - what functions does 
>>> Integer (or sub types) have, that my type does not?
>>>
>>> and ponies!
>>>
>>> cheers, andrew
>>>
>>> ps i just looked at TypeCheck.  check_loop_types is going to be sooo 
>>> useful....
>>>
>>>
>>>
>>> On Tuesday, 25 February 2014 20:13:07 UTC-3, Leah Hanson wrote:
>>>
>>>> I'm planning to add a "which methods are defined for subtypes of this 
>>>> type" function to TypeCheck.jl this week. If there's any specific behavior 
>>>> you want it to have, let me know. :)
>>>>
>>>> -- Leah
>>>>
>>>>
>>>> On Tue, Feb 25, 2014 at 2:52 PM, David Moon <dave...@alum.mit.edu>wrote:
>>>>
>>>>> On Tuesday, February 25, 2014 7:14:37 AM UTC-5, David Moon wrote:
>>>>>>
>>>>>>
>>>>>> The advantage of making it an explicit concept in the language, 
>>>>>> rather than just defining a method that signals an error, is that it can 
>>>>>> be 
>>>>>> checked at compile time.
>>>>>>
>>>>>
>>>>> In Julia, compile time is load time.  Specifically, after evaluating a 
>>>>> top-level expression (which may have loaded a whole lot of files) check 
>>>>> each newly defined datatype or bitstype to see if there are any required 
>>>>> methods that involve that type or its supertypes.  If so, check if an 
>>>>> instance of the newly defined type would have all the required methods 
>>>>> applicable to it in the appropriate argument position.
>>>>>
>>>>
>>>>
>>

Reply via email to