OS/X OpenGL

[Maurizio Cimadamore]

We have added this to 21, in the form of an “or” instance method:

https://git.openjdk.org/jdk/pull/13954

So:

|SymbolLookup MY_LOOKUP = libraryLookup("lib1", arena) 
.or(libraryLookup("lib2", arena)) .or(libraryLookup("lib3", arena)) 
.or(libraryLookup("lib4", arena)) ... .or(libraryLookup("libN", arena)); |

Cheers
Maurizio

On 10/05/2023 15:26, Michael Hall wrote:

        On May 10, 2023, at 8:52 AM, Maurizio Cimadamore

        maurizio.cimadamore at oracle.com
        <http://mailto:maurizio.cimadamore@oracle.com> wrote:

        On 10/05/2023 14:05, Michael Hall wrote:

            Basically you’re saying you need a length 5 chain that needs to
            be searched for the leaf? Yes, ultimately you would at some
            point. Possibly you would be over working a lambda? I thought it
            might be more a convenience to the developer if they have a
            collection of Path’s they could specify them in one
            invocation of
            libraryLookup and the api would manage the necessary multiple
            SymbolLookup’s searching for the leaf. The developer can of
            course manage this themselves although again at some point maybe
            not with a lambda.

            What I’m saying is this:

        |SymbolLookup MY_LOOKUP = SymbolLookup.compose(
        libraryLookup("lib1", arena), libraryLookup("lib2", arena),
        libraryLookup("lib3", arena), libraryLookup("lib4", arena), ...
        libraryLookup("libN", arena));|

        Doesn’t seem bad. You get back a single lookup, which is then used
        to perform several lookups. If we can achieve same behavior via
        simple composition, that seems better/more flexible to me. Symbol
        lookups are created once (at the start of your application) and
        then “forgot”, so I don’t think there’s a lot of value in making
        the above more succinct (at the expense of API regularity).

        Maurizio

        Ah, sorry, hadn’t seen compose yet. No, not bad at all.

    Thanks, Mike

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230522/08dabee6/attachment-0001.htm>