[dylan] Duplicated format implementation in common-dylan and io libraries
Bruce Mitchener <[email protected]> Fri, 13 Nov 2015 09:46:05 +0700
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CA+esKjPMJDNrFSAZq60vTUQMPz8OhNNPooswQMhphRrv+XnEug@mail.gmail.com> |
--===============0614577509== Content-Type: multipart/alternative; boundary=047d7bdc9e4a9d52630524630f15 --047d7bdc9e4a9d52630524630f15 Content-Type: text/plain; charset=UTF-8 TLDR: I propose breaking up the io library and reducing the duplication of format code between common-dylan and io by sharing the implementation that is currently present within io. More details and motivation below. Full email: A common source of confusion is that common-dylan has one implementation of format while the io library provides another (that is more complete). This means that someone that is extending print-object or print-message will have unexpected results if someone happens to use the implementation from common-dylan, since it isn't extensible. I'm not sure what the original motivation was for this split. Perhaps it was that the IO library was larger, perhaps it was the usage of the FFI, or something else entirely or just simply inertia. In Mindy, I am prototyping a common-dylan implementation and there, I just let common-dylan depend on the io library and use the same implementation of format. This seems to work out pretty well and definitely eliminates a source of confusion. This also shows up when I'm fixing things like "How do we print type objects?" as I have to implement the same functionality in both common-dylan and io. The io library provides a number of things that not everyone needs, like indenting streams, pretty printing, etc so it may be best to not go and have common-dylan depend directly upon the io library in Open Dylan. My proposal, pending further investigation, is that we look at splitting the io functionality into 2 sets: slim-io and io. The slim-io functionality would either move to a separate library that both common-dylan and io can depend upon, or it would be folded directly into the common-dylan library. Thoughts? - Bruce --047d7bdc9e4a9d52630524630f15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>TLDR:</div><div><br></div><div>I propose breaking up = the io library and reducing the duplication of format code between common-d= ylan and io by sharing the implementation that is currently present within = io.</div><div><br></div><div>More details and motivation below.</div><div><= br></div><div>Full email:</div><div><br></div>A common source of confusion = is that common-dylan has one implementation of format while the io library = provides another (that is more complete).<div><br></div><div>This means tha= t someone that is extending print-object or print-message will have unexpec= ted results if someone happens to use the implementation from common-dylan,= since it isn't extensible.</div><div><br></div><div>I'm not sure w= hat the original motivation was for this split. Perhaps it was that the IO = library was larger, perhaps it was the usage of the FFI, or something else = entirely or just simply inertia.</div><div><br></div><div>In Mindy, I am pr= ototyping a common-dylan implementation and there, I just let common-dylan = depend on the io library and use the same implementation of format.=C2=A0 T= his seems to work out pretty well and definitely eliminates a source of con= fusion.</div><div><br></div><div>This also shows up when I'm fixing thi= ngs like "How do we print type objects?" as I have to implement t= he same functionality in both common-dylan and io.</div><div><br></div><div= >The io library provides a number of things that not everyone needs, like i= ndenting streams, pretty printing, etc so it may be best to not go and have= common-dylan depend directly upon the io library in Open Dylan.</div><div>= <br></div><div>My proposal, pending further investigation, is that we look = at splitting the io functionality into 2 sets: slim-io and io.=C2=A0 The sl= im-io functionality would either move to a separate library that both commo= n-dylan and io can depend upon, or it would be folded directly into the com= mon-dylan library.</div><div><br></div><div>Thoughts?<br><div><br></div><di= v>=C2=A0- Bruce</div><div><br></div></div></div> --047d7bdc9e4a9d52630524630f15-- --===============0614577509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ hackers mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/hackers --===============0614577509==--