Le 21/02/2012 20:01, H. S. Teoh a écrit :
> On Tue, Feb 21, 2012 at 07:57:37PM +0100, deadalnix wrote:
>> Le 21/02/2012 03:33, Robert Jacques a écrit :
> [...]
>>> Aren't __traits and opDispatch fun?
>>
>> opDispatch is nice, but rather incomplete. It doesn't handle template
>> methods for example.
>
> Does RTTI handle template methods?
>

I'm not aware of any language that have both template and RTTI. So I'm clueless about this.

Le 22/02/2012 06:47, H. S. Teoh a écrit :
> On Tue, Feb 21, 2012 at 07:43:32PM -0500, Jonathan M Davis wrote:
>> On Tuesday, February 21, 2012 14:15:03 Andrei Alexandrescu wrote:
>>> I thought I was pushing the generics angle, and OO people explained
>>> it to me that that was wrong.
>
> I've changed my mind. Now I'm trying to see if the generics angle has
> some possibilities. Maybe, maybe not, but we'll never know without
> experimenting with it. I think your is_transient idea can be expanded
> upon.
>
> The way exceptions are currently implemented, they only carry
> information, not behaviour, as Jonathan said rightly.  The try/catch
> mechanism essentially reduces to "I've hit a problem I don't know how to
> solve, here's a description of it". There's no behaviour in there. The
> throwing code has already given up.  It's up to the catcher to interpret
> the description of the problem and figure out how to recover. To recover
> well, the catcher must know the intimate details of the problem well. So
> you have the situation of a specific catcher catching a specific
> Exception subclass. This is not an ideal situation, because now
> high-level code needs to know the specifics of low-level errors.
>
> With your is_transient idea, though, this begins to change. Now we're no
> longer just describing the problem.  When is_transient=1, it means the
> thrower is suggesting that perhaps retrying would help. Of course, it's
> up to the catcher whether or not to follow through with this suggestion,
> but it's one step up from "here's a description of the problem, figure
> out the solution yourself". But now the catcher doesn't necessarily have
> to know the specifics of the low-level problem. It knows at least one
> strategy that might fix the problem, regardless of what the problem is:
> retry the operation. This is good, because the low-level code, which
> knows the problem best, can offer a useful suggestion (retry). The
> high-level code can just take the suggestion or not; it no longer needs
> to know low-level details.
>
> But why stop there? Since the low-level code knows all the dirty details
> about the problem, it's in the best position to offer meaningful
> recovery suggestions. It just has to communicate these possible recovery
> strategies to the high-level code, and let the high-level code decide
> what to do. The high-level code doesn't need to know how to implement
> these strategies -- it's not in the best position to know that anyway.
> It just knows, here's a list of recovery strategies, I can go ahead with
> one of them, or just call it quits and unwind the stack. The low-level
> code is what implements each strategy.
>
> Of course, in order for the high-level code to meaningfully choose
> between alternative strategies, the strategies themselves must be
> generic concepts; otherwise we're still tying high-level code to
> low-level details. So we need to identify generic categories of
> exceptions for which this kind of generic recovery is meaningful --
> which is what I've done in another post.
>
> I won't repeat the details here, but I just want to say that I think
> this angle merits some investigation. It allows us to factor out
> exceptions which can be resolved by commonly used recovery strategies so
> that we don't have to keep writing tons and tons of exception-specific
> recovery code everywhere. Some specific code is still needed, no doubt,
> there's always special cases that need specific handling.  But if enough
> exceptions can be adequately dealt with generically, then we don't need
> to write specific code for them. We can simply reuse generic recovery
> solutions.
>
>
> T
>

100% Agree.

Additionnaly, I would mention that the transient isn't a caracteristic of the Exception, but of the recovery strategy.

On 2/22/12 1:22 AM, Jacob Carlborg wrote:
> Now I'm completely lost. According to what I've read this is thread this
> is exactly what you want to do, put the formatting inside the exceptions.

No, just have exceptions inform an external formatter.

Andrei

On Tue, 21 Feb 2012 21:51:34 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 2/21/12 6:11 PM, Robert Jacques wrote:
>> On Tue, 21 Feb 2012 09:12:57 -0600, Adam D. Ruppe
>> <destructionator@gmail.com> wrote:
>>
>>> On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques
>>> wrote:
>>>> Nope. See
>>>> (https://jshare.johnshopkins.edu/rjacque2/public_html/ )
>>>
>>>
>>> Any luck in getting the required patches into phobos?
>>>
>>> I'd love to see this full thing in there for the next release.
>>>
>>> It rox.
>>
>> I'm in the process of cleaning up the required patches and submitting
>> them. The first one's already in
>> (https://github.com/sandford/phobos/commit/8b845d2a50bc20993afed7306f3d84921e4ac54b).
>> I've almost got appender ready.
>
> Are the changes substantial enough to put them through the review process?
>
> Andrei

To Variant? Yes, definitely. To Appender? I don't think so. There is an slight change in API behavior necessitated by performance considerations, but I don't think it warrants a review by the community at large. Specifically, appender's internal data structure is now sealed, which means that .data must always make a copy. My preference would be to deprecate .data in favor of a .dup/.idup pair. It'll break a bunch of code (which I don't like), but it will make sure no one is calling .data twice in a row, resulting in a silent performance problem.

On Tue, Feb 21, 2012 at 6:32 PM, deadalnix <deadalnix@gmail.com> wrote:
> Le 21/02/2012 00:23, Andrei Alexandrescu a écrit :
>
>> On 2/20/12 4:44 PM, Juan Manuel Cabo wrote:
>>>
>>> HAhaha, it sometimes feel as though people are afraid that the
>>> Variant[string]
>>> idea is to never use plain old variables and never use exception
>>> subclasses. :-)
>>>
>>> On the contrary, the idea is so that plain old variables and exception
>>> subclasses
>>> can be created for the right reasons, and to remove cases where they need
>>> to be created for the wrong reasons.
>>
>>
>> Yah, I think there's a lot of confusion and consequent apprehension regarding this. Thanks for attempting to clarify things.
>>
>> Andrei
>>
>
> So it doesn't help. Dulb subclasses of Exceptions are done mostly to be able to catch them. To avoid useless subclasses, we need a more precise way to catch Exception than the type only.
>

Agreed. I would love it if catch worked using a structural/pattern matching mechanism. Something like template's if clause or like Scala pattern matching...

-Jose
> This Variant[string] doesn't help.

On Wed, Feb 22, 2012 at 11:18:13AM +0100, deadalnix wrote:
> Le 21/02/2012 20:01, H. S. Teoh a écrit :
[...]
> >Does RTTI handle template methods?
> >
> 
> I'm not aware of any language that have both template and RTTI. So I'm clueless about this.

Doesn't C++ have RTTI?


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

Le 22/02/2012 16:33, H. S. Teoh a écrit :
> On Wed, Feb 22, 2012 at 11:18:13AM +0100, deadalnix wrote:
>> Le 21/02/2012 20:01, H. S. Teoh a écrit :
> [...]
>>> Does RTTI handle template methods?
>>>
>>
>> I'm not aware of any language that have both template and RTTI. So I'm
>> clueless about this.
>
> Doesn't C++ have RTTI?
>

You could argue that, but IMO, it look more like a stub than a real functionnality of the language.

On Tue, 21 Feb 2012 14:19:17 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/21/12 5:55 AM, Regan Heath wrote:
>> On Sun, 19 Feb 2012 23:04:59 -0000, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On 2/19/12 4:00 PM, Nick Sabalausky wrote:
>>
>>>> Seriously, how is this not *already* crystal-clear? I feel as if
>>>> every few
>>>> weeks you're just coming up with deliberately random shit to argue so
>>>> the
>>>> rest of us have to waste our time spelling out the obvious in insanely
>>>> pedantic detail.
>>>
>>> It sometimes happened to me to be reach the hypothesis that my
>>> interlocutor must be some idiot. Most often I was missing something.
>>
>> I get the impression that you find "Devil's advocate" a useful tool for
>> generating debate and out of the box thinking.. there is something to be
>> said for that, but it's probably less annoying to some if you're clear
>> about that from the beginning. :p
>
> Where did it seem I was playing devil's advocate? Thanks.

"Devil's Advocate" is perhaps not the right term, as you don't seem to ever argue the opposite to what you believe.  But, it occasionally seems to me that you imply ignorance on your part, in order to draw more information from other posters on exactly what they think or are proposing.  So, some get frustrated as they feel they have to explain "everything" to you (and not just you, there have been times where - for whatever reason - it seems that anything less than a description of every single minute detail results in a miss understanding - no doubt partly due to the medium in which we are communicating).

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote:
> To Variant? Yes, definitely. To Appender? I don't think so. There is an slight change in API behavior necessitated by performance considerations, but I don't think it warrants a review by the community at large. Specifically, appender's internal data structure is now sealed, which means that .data must always make a copy. My preference would be to deprecate .data in favor of a .dup/.idup pair. It'll break a bunch of code (which I don't like), but it will make sure no one is calling .data twice in a row, resulting in a silent performance problem.

I've definitely written code that needed to get at data while appending. I would consider it to be a huge downside to not be able to efficiently get at the current state of the array within the appender. Why on earth would you seal it?

- Jonathan M Davis

On Wed, Feb 22, 2012 at 11:53:39AM +0100, deadalnix wrote: [...]
> Additionnaly, I would mention that the transient isn't a caracteristic of the Exception, but of the recovery strategy.

Technically correct. Though I'm playing with the idea of making recovery strategies a property of an exception - since a recovery strategy is meaningless without an associated exception (or problem). I need to think this through a bit more, though, as to how to correctly implement this.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst