<div dir="ltr">Hi,<div><br></div><div>1. I'm totally against introducing pragma's (perhaps they already exist in Cuis, I don't know).</div><div><br></div><div>First of all because they are not Smalltalk, and second because they are not needed.</div><div><br></div><div>What would be wrong with simply introducing a convention and adding a method cuisPublicSelectors to a class?</div><div><br></div><div>To avoid seeing them on the instance side, there could also be cuisPublicInstanceSelectors and cuisPublicClassSelectors on the class side.</div><div><br></div><div>At the top these would be defined as self allSelectors.</div><div><br></div><div>If someone wanted to view only the public selectors in a browser, they would check the checkbox for that and the browser would hide the non-public selectors.</div><div><br></div><div>Or the browser could show a nice public interface report added to the class comment.</div><div><br></div><div>2. On another point: interfaces such as indexable could simply be described by creating a class CuisInterfaceSpecification which gets a subclass for each interface specified. The methods belonging to the interface are defined and get a comment explaining the semantics of the method. This makes it easy for tools to check which interfaces are (probably) implemented by a class. If desired, each method could be additionally defined to return a MethodSpecification object that knows about preconditions, invariants, return values, argument and return types/interfaces...but then it becomes progressively more complicated.</div><div><br></div><div>But anyway, in this way whoever thinks it's important enough, can add the info (for public selectors of a class or for whole interface specifications) without anyone who is not interested in that needing to know or care about that.</div><div><br></div><div>In my mind that gels well with Cuis' philosophy of simplicity. But I could be missing the whole point...</div><div><br></div><div>Cheers, Peter</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 9:19 PM, Phil (list) <span dir="ltr"><<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2015-08-03 at 15:49 -0300, Juan Vuletich wrote:<br>
> Hi Doug,<br>
><br>
> On 8/2/2015 4:04 AM, Douglas Brebner wrote:<br>
> > On 19/07/2015 22:38, Phil (list) wrote:<br>
> >> Ready to go... we just need to agree on how to do it (pragma/method<br>
> >> call/method category/method name?) Also, this is most definitely<br>
> >> related to the 'Canonical test cases?' thread from a few months ago<br>
> >> as these types of test cases / docs are part of the backfill I was<br>
> >> referring to.<br>
> ><br>
> > I vaguely recall that many years ago there was a project called<br>
> > SmallInterfaces that let you define public interfaces to objects. (Or<br>
> > something like that). Would that be a good way to document the<br>
> > public/private api using code?<br>
> ><br>
> > (sorry for being so vague but I've been awake for 24+ hours now)<br>
><br>
> Thanks for the pointer. I took a look at it. It is quite like Java<br>
> interfaces. The tools are interesting. But I see several downsides:<br>
><br>
> - Each interface is a class. Each method in the protocol is an actual<br>
> method. If we use this to document all public protocols in Cuis, it<br>
> would mean a lot of new classes and methods.<br>
> - The source code of (for example) OrderedCollection>>at: would not<br>
> include the information of it belonging to interface "Indexable".<br>
> Without additional support from tools users can't tell whether a message<br>
> is public protocol or not. And the base image / package maintainer can't<br>
> easily see he's about to change a public api.<br>
><br>
> I think a method pragma, that includes the name of the protocol avoids<br>
> these issues and is a better choice.<br>
><br>
<br>
</div></div>I agree.  Let's keep it as simple as possible and see how far that gets<br>
us.<br>
<div class="HOEnZb"><div class="h5"><br>
> Cheers,<br>
> Juan Vuletich<br>
><br>
> _______________________________________________<br>
> Cuis mailing list<br>
> <a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
> <a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" rel="noreferrer" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" rel="noreferrer" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></div><br></div>