I *think* so.
On Fri, Jun 5, 2020 at 12:45 PM Steve Ebersole wrote:
> Load event handling does not have "anything" parameters. Am I
> understanding you correctly?
>
> On Fri, Jun 5, 2020, 11:42 AM Gail Badner wrote:
>
>> Hi Steve,
>>
>> Sorry, I have not read the entire thread carefully, so pl
Load event handling does not have "anything" parameters. Am I
understanding you correctly?
On Fri, Jun 5, 2020, 11:42 AM Gail Badner wrote:
> Hi Steve,
>
> Sorry, I have not read the entire thread carefully, so please disregard if
> not relevant.
>
> Would this provide functionality like what w
Hi Steve,
Sorry, I have not read the entire thread carefully, so please disregard if
not relevant.
Would this provide functionality like what we discussed for an
OperationContext?
https://hibernate.atlassian.net/browse/HHH-10478
Thanks,
Gail
On Fri, May 29, 2020 at 4:21 AM Steve Ebersole wrot
If/when it comes to needing that, I kind of like that continuation design.
But I agree, Yoann is right - let's leave it off until needed or until we
have specific requirements.
Thanks everyone!
On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero wrote:
> On Fri, 29 May 2020 at 07:22, Yoann Rodiere
On Fri, 29 May 2020 at 07:22, Yoann Rodiere wrote:
>
> +1 not to add surround capability initially. Sounds better to start simple
> and make things more complex when we actually need it :)
Right. I didn't mean to raise additional requirements without having
investigated those tracing libraries -
+1 not to add surround capability initially. Sounds better to start simple
and make things more complex when we actually need it :)
Yoann Rodière
Hibernate Team
yo...@hibernate.org
On Fri, 29 May 2020 at 07:25, Sanne Grinovero wrote:
> Yes, I agree.
>
> On Thu, 28 May 2020, 22:11 Steve Ebersol
Yes, I agree.
On Thu, 28 May 2020, 22:11 Steve Ebersole, wrote:
> Wanted to clarify -
>
> Regarding incremental addition of "surround listeners", so long as we are
> all in agreement that this simply means there will be absolutely no
> surround capability ***initially*** then I am fine with that
Wanted to clarify -
Regarding incremental addition of "surround listeners", so long as we are
all in agreement that this simply means there will be absolutely no
surround capability ***initially*** then I am fine with that.
On Thu, May 28, 2020 at 4:10 PM Steve Ebersole wrote:
> Hm, the dynamic
Hm, the dynamic enable/disable stuff should be easy to handle, no? Depends
on what specific library you are thinking of and exactly how that detail
gets propagated to us. At the end of the day, its really as simple as
protecting the creation of some of these objects with `if (enabled)`-type
check
On Thu, 28 May 2020 at 21:27, Steve Ebersole wrote:
>
> Any thoughts on this "continuation" approach?
I love the pattern! Maybe we'll need also some ability to not capture
the state for events which don't have any?
I wonder if that implies we'll need two different event contracts: one
for the li
Any thoughts on this "continuation" approach?
Or maybe its just not important (yet) to handle "surround" handling?
On Wed, May 27, 2020 at 9:27 AM Steve Ebersole wrote:
> Inline...
>
> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero
> wrote:
>
>> At high level I agree, just have 3 more thought
Inline...
On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero wrote:
> At high level I agree, just have 3 more thoughts:
>
> # Regarding the "swap" of information between listeners - could that
> even work? I might have misunderstood something, but wouldn't we
> require listeners to run in some spec
At high level I agree, just have 3 more thoughts:
# Regarding the "swap" of information between listeners - could that
even work? I might have misunderstood something, but wouldn't we
require listeners to run in some specific order for such swapping to
work?
# The "surround advice" you mention fo
The overall concept with event+listeners initially was that listeners would
"collaborate" which each other with the event as a token for common
information. The "result" of the operation was made part of the event to
facilitate this design - the idea being that one listener might swap the
result,
Hi,
> I think that's a great idea
Same here!
Another advantage is we separate the "SPI"/internal interface (Handler)
from the API that can be implemented by users (listeners).
That could be a great help moving forward to evolve Hibernate ORM without
breaking APIs.
> but I wonder about the reada
Hi Steve,
looks like you're getting rid of the "event object"? No more events to
be allocated?
I think that's a great idea, but I wonder about the readability of the
code. With "inline types" coming soon to the JDK, the event object
types could be great candidates to be converted into inline?
If
Historically we made a terrible design mistake with the event system as a
whole. This has both a confusing design impact and a very real performance
impact. The main problem is the smashing together of things that handle
events and things that listen to such events.
In working on a problem in v6
17 matches
Mail list logo
