This doesn't work at preset you can 'extend' existing verbs in other modules to your hearts content, but you can't add a new one.
On Thursday, May 14, 2015 at 9:21:44 AM UTC-4, Tom Breloff wrote: > > Would it be possible for an external library to "add" a method to Base? > My question is if there are 2 independent packages that want to define > functionality on a verb, but that verb doesn't yet exist in Base. What > would happen if they both defined a verb that they think naturally belongs > in Base: > module A > Base.XXX(x, a) = "A" > end > > module B > Base.XXX(y) ="B" > end > > Should this now be a method in Base with 2 definitions, or should this be > illegal? Currently you get a UndefVarError (on my version at least... I'm > still on the commit just before the tuple overhaul until I have time to fix > my codebase). > > It *seems* like it could be dangerous to allow external packages to add > to Base, but I don't actually see the scenario where it breaks anything. > However if you allow the behavior... if 2 packages both decide that there > should be a generic verb in Base, it will automatically be added and the > methods merged as if there was an empty definition already. I would hate > to have to submit pull requests to core Julia just to have an empty method > definition added to Base. > > > On Wednesday, May 13, 2015 at 9:58:58 PM UTC-4, Tony Kelman wrote: >> >> There's also at least one issue open on the topic of declaring a generic >> function without implementing any methods. Things like "non-mutating >> setfield" would probably be good candidates to reserve names for in Base >> even if there aren't any types in Base where that generic function makes >> sense. >> >> >> On Wednesday, May 13, 2015 at 5:08:19 PM UTC-7, Kevin Squire wrote: >>> >>> If you haven't yet, you should check out FunctionalCollections.jl, which >>> "solves" this by not allowing assignment in this way, instead defining >>> `assoc` and `dissoc`. >>> >>> Cheers, >>> Kevin >>> >>> On Wed, May 13, 2015 at 3:05 PM, Michael Francis <mdcfr...@gmail.com> >>> wrote: >>> >>>> On a mutable associative it is valid to execute the following ( where x >>>> is associative ) >>>> >>>> x = Dict() >>>> y = x[:a] = 1.23 >>>> >>>> >>>> >>>> y has the value 1.23 >>>> >>>> on an immutable collection what does the following mean ? >>>> >>>> x = @NT( ) >>>> y = x[:a] = 1.23 >>>> >>>> >>>> Do I get a new version of x with the key :a and the value 1.23 ? >>>> >>>> >>>> On Wednesday, May 13, 2015 at 5:31:27 PM UTC-4, David Gold wrote: >>>>> >>>>> It also brings up an asymmetry between the overloaded [] operator for >>>>> immutable collections, where y = x[:a] is valid but x' = x[:b] = 1.23 >>>>> is not. I'm ok with this, but it does lead to some confusion. >>>>> >>>>> Would you please elaborate on this? I'm not sure I understand (I'm >>>>> confident the issue is on my end). >>>>> >>>>> On Wednesday, May 13, 2015 at 3:03:11 PM UTC-4, Michael Francis wrote: >>>>>> >>>>>> A little bit of both, I have defined what I would consider common >>>>>> verbs, they happen to not exist in Base today. So either they get >>>>>> added to Base, which in this instance may be the right thing or at some >>>>>> point in the future they will conflict and breakage will ensue. >>>>>> >>>>>> It also brings up an asymmetry between the overloaded [] operator for >>>>>> immutable collections, where y = x[:a] is valid but x' = x[:b] = 1.23 is >>>>>> not. I'm ok with this, but it does lead to some confusion. >>>>>> >>>>>> Most languages sidestep this by not having the ! annotation for >>>>>> mutation and rely on the type/number of arguments to define the >>>>>> behavior. >>>>>> I'm not necessarily advocating for this, but I would like some input >>>>>> from >>>>>> others on this. >>>>>> >>>>>> >>>>>> On Wednesday, May 13, 2015 at 2:51:47 PM UTC-4, Josh Langsfeld wrote: >>>>>>> >>>>>>> Is your concern that some other package might also export >>>>>>> non-mutating setindex and delete, thereby conflicting with yours? Or >>>>>>> just >>>>>>> that they should exist in Base? >>>>>>> >>>>>>> On Wednesday, May 13, 2015 at 2:35:44 PM UTC-4, Michael Francis >>>>>>> wrote: >>>>>>>> >>>>>>>> I added methods to NamedTuples.jl to support merge, set and delete. >>>>>>>> Since NamedTuples are essentially immutable dictionaries it seems >>>>>>>> incorrect >>>>>>>> to use the ! forms of setindex and delete. I now have an issue that >>>>>>>> these >>>>>>>> are not defined in base. How best to solve this? This is indirectly >>>>>>>> related >>>>>>>> to the thread on function name collapse, but any suggestions ? >>>>>>>> >>>>>>>> nt = @NT( a=>1, b=>2, c=>3 ) >>>>>>>> x = NamedTuples.setindex( nt, :x, 123 ) >>>>>>>> NamedTuples.delete( x, :a) # (b=>2,c=>3,x=>123) >>>>>>>> merge( nt, @NT( d => "hello", e => "world")) # ( >>>>>>>> a=>1,b=>2,c=>3,d=>"hello",e=>"world") >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>
