-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand classes to avoid needing some rules #38
Comments
Yeah, I'm not a big fan of using |
It's possible to make the change in a way that's invisible to users, import Secret (Graph(.....), gmap, ....) There are some other ideas I have that would be more major-versiony than On Aug 29, 2016 9:52 PM, "Ivan Lazar Miljenovic" [email protected]
|
Oh yes, and quit that horrible "Check for empty, then use a partial On Aug 29, 2016 10:05 PM, "David Feuer" [email protected] wrote:
|
Well, the latter will definitely require a major version bump ;-) In reality, I'd like to have the time to write a new graph library from the ground up... but I've been saying that for about 10 years now >_> What makes expanding the class major version bump required is from how you have to import functions; this is classified as a breaking change by the Package Versioning Policy. |
It's definitely possible to avoid that. At worst, you can use module Public where but I don't think you have to go that far. I believe that having the On Aug 29, 2016 10:11 PM, "Ivan Lazar Miljenovic" [email protected]
|
Ugh. I just checked. The easy ways don't work, as you expected (silly On Mon, Aug 29, 2016 at 10:19 PM, David Feuer [email protected] wrote:
|
Actually, I think the best solution for this would be Backpack if/when it becomes usable. But back in the real world... I suppose my main concern about this kind of hidden class change is that on the off chance someone else is implementing their own instances of |
They absolutely do not need to update their code the first time. Their code On Mon, Aug 29, 2016 at 11:57 PM, Ivan Lazar Miljenovic <
|
To clarify: if they want to take advantage of the new classes to not have to use their own And it still breaks the PVP, so I'm not sure whether it could potentially have other impacts. I have no problem with the next version being a major version bump with this in there, though planning around exactly where the border between being in the class and being a derived function will need to be determined. |
(I suppose if nothing else updating FGL to have a larger type class gives me something to do at ICFP :p) |
Some
RULES
pragmas are used to specialize functions to specific graph implementations. I believe most or all of these could be eliminated by adding the relevant functions toGraph
orDynGraph
. If you are concerned that some of them may not really belong in the API, and don't know what user-friendly methods to add to support them, you can hide those methods by defining the class in an "internal" module, and only export some of its methods. Using the class system instead of rules, when possible, guarantees that the preferred implementation will always be used.The text was updated successfully, but these errors were encountered: