• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Opinion on ERXKey type parameterization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opinion on ERXKey type parameterization


  • Subject: Re: Opinion on ERXKey type parameterization
  • From: Paul Hoadley <email@hidden>
  • Date: Wed, 29 Mar 2017 09:19:27 +1030

Hi Samuel,

Last question first:

Is there any benefit to specify the type as NSArray<T> for these ERXKey I do not see ?

It’s hard to find a practical benefit. (There’s obviously little, if any, practical detriment to leaving it how it is—presumably everyone has been doing it the existing way in numerous projects over many years.) But I think there are cracks in the type-safety that gets advertised. For example, ERXGenericRecord.valueForKey(ERXKey<T> key) will attempt a cast to the wrong type if you feed it a to-many relationship key.

However:

On 29 Mar 2017, at 12:25 am, Samuel Pelletier <email@hidden> wrote:

After paying a lot with ERXKey, I came to the conclusion that the current templates are correct. Using the collection as the type seems good at first but if you use aggregation functions they no longer works.

ERXKey have 2 typed methods to get the value: 
public T valueInObject(Object obj)
public NSArray<T> arrayValueInObject(Object obj) 

When you know the value is an array, use the arrayValueInObject variant. It always works even when traversing toMany relationships to get all the firstName of contacts of some entity like this:

NSArray<String> firstNames = SomeEntity.CONTACTS.dot(Contact.FIRST_NAME).arrayValueInObject(anInstanceOfSomeEntity);

If you want the latest birthDate:

LocalDate lastBirthDate = SomeEntity.CONTACTS.atMax(Contact.BIRTH_DATE).valueInObject(anInstanceOfSomeEntity);

There is many operations available and it is probably not possible to determine the final type of an ERXKey chain (array or instance) and using the 2 value getters always works.

For relationships, I do not think it can really create confusion but if your key represent an array of String or number values, you will probably use aggregate key one day that will no longer works as expected because your ERXKey have a NSArray type.

That seems like a good argument for leaving it as is.

I think this is the money quote:

When you know the value is an array

I was trying to do something where I didn’t want to make any assumptions about the value, assuming that the value type was encoded in the ERXKey itself. Maybe this just isn’t possible.

What do you think about the issue of calling ERXGenericRecord.valueForKey(ERXKey<T> key) on a to-many key, Samuel? Anyone else got any thoughts on all this?


-- 
Paul Hoadley
http://logicsquad.net/
https://www.linkedin.com/company/logic-squad/



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Opinion on ERXKey type parameterization
      • From: Paul Hoadley <email@hidden>
References: 
 >Opinion on ERXKey type parameterization (From: Paul Hoadley <email@hidden>)
 >Re: Opinion on ERXKey type parameterization (From: Samuel Pelletier <email@hidden>)

  • Prev by Date: Re: Set case insensitive unique index with ERXMigrations
  • Next by Date: Re: Opinion on ERXKey type parameterization
  • Previous by thread: Re: Opinion on ERXKey type parameterization
  • Next by thread: Re: Opinion on ERXKey type parameterization
  • Index(es):
    • Date
    • Thread