X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "Markus Ruggiero (rucotec)" Received: from miniserver.rucotec.ch ([213.189.151.242] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 26366746 for webobjects-dev@wocommunity.org; Sat, 28 Aug 2021 17:03:34 +0200 Received-SPF: none receiver=post.selbstdenker.com; client-ip=213.189.151.242; envelope-from=markus.ruggiero@rucotec.ch Received: from localhost (localhost [127.0.0.1]) by miniserver.rucotec.ch (Postfix) with ESMTP id 26C602E2F2EC for ; Sat, 28 Aug 2021 17:03:13 +0200 (CEST) Received: from miniserver.rucotec.ch ([127.0.0.1]) by localhost (miniserver.rucotec.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrK_ukg5mBMP for ; Sat, 28 Aug 2021 17:02:56 +0200 (CEST) Received: from smtpclient.apple (unknown [192.168.56.49]) by miniserver.rucotec.ch (Postfix) with ESMTPSA id B38372E2F2CD for ; Sat, 28 Aug 2021 17:02:56 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_E12A6E7E-618F-49A1-8535-D6B2CFA34B47"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [WO-DEV] ERXGenericRecord takeValueForKey Date: Sat, 28 Aug 2021 17:02:55 +0200 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: <64C033AD-41AC-4B9B-A067-214E3ABF4905@rucotec.ch> X-Mailer: Apple Mail (2.3654.120.0.1.13) --Apple-Mail=_E12A6E7E-618F-49A1-8535-D6B2CFA34B47 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B425D4F-0069-46A7-9B2D-65D1CA393A7A" --Apple-Mail=_8B425D4F-0069-46A7-9B2D-65D1CA393A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi OC, I will try to answer your question from a conceptual angle... > On 26 Aug 2021, at 03:50, ocs@ocs.cz = wrote: >=20 > Hi there, >=20 > I must be missing something darn obvious; looks like I've missed EOF = 101 somehow :/ >=20 Nothing to do with EOF. Well, not directly. See below... > My EO class, which extends ERXGenericRecord, does not implement = modelled property setters. Thus, I assumed takeValueForKey would always = fall through handleTakeValueForUnboundKey. Seems not. >=20 > I've overridden the methods like this: >=20 > =3D=3D=3D > class OCSEnterpriseObject extends ERXGenericRecord { > static boolean canAccessFieldsDirectly { NO } > void takeValueForKey(value,String key) { > println "???takeValueForKey $key" > //super.takeValueForKey(value, key) // precisely same behaviour as = with the thing below, no difference > = NSKeyValueCoding.DefaultImplementation.takeValueForKey(this,value,key) > } > void handleTakeValueForUnboundKey(value,String key) { > println "???handleTakeValueForUnboundKey $key" > // ... some stuff to simulate setter (eventually using = takeStoredValueForKey), not relevant, for it is never called > } > ... > } > =3D=3D=3D >=20 > It does NOT work as (I've na=C3=AFvely) presumed. >=20 Your presumption is wrong. > When eo.takeValueForKey(o,key) is called, I can always see = =E2=80=9C???takeValueForKey=E2=80=9D (naturally), but I *never ever* see = =E2=80=9C???handleTakeValueForUnboundKey=E2=80=9C for any key amongst = modelled attributes. Nothing other (known to me) gets called =E2=80=94 = not even takeStoredValueForKey, which I've also overridden to log =E2=80=94= , but the value is set all right in the EO. >=20 > Only if foo is a random (non-existing, non-modelled) string, I can see = =E2=80=9C???handleTakeValueForUnboundKey=E2=80=9C. >=20 > Looks like there's some trick in = NSKeyValueCoding.DefaultImplementation.takeValueForKey which recognises = modelled attributes in EOGenericRecord and fill their values directly, = without falling to handleTakeValueForUnboundKey?!? Weird. >=20 No, not weird, not at all. > Or I must be doing something very far wrong. >=20 Ditto no. Your (and most other folks=E2=80=99s) thinking of key value coding is = wrong and way too technical. What actually happens is the following: Conceptually in object oriented programming objects communicate with = each other. This is a 2-fold process. One object sends a message to = another object and the receiving object then acts on that message. This = distinction is beautifully visible in Objective-C where there are two = syntaxes available. One, the classic C call, relies on early binding. = This is just a simple function call and the called code is determined at = compile time. The other syntax, the one most programmers don=E2=80=99t = like (because they don=E2=80=99t understand it), is the [myObj = myMessage] thing with the square brackets. This is really message = passing in the true sense of the OO paradigm. In this sense you can send = any message to any object, even to a non-existing object, and you either = get a reaction or you don=E2=80=99t because the receiving object = understands your message or is does not. Did you ever wonder why in the = WO docs the word =E2=80=9Creceiver=E2=80=9D occurs so often? Key value coding in WO is a technical implementation of this mechanism. = In =E2=80=9Cmodern=E2=80=9D languages like Java one cannot send an = arbitrary message to any object - there is simply no syntax for it. KVC = is the underlying technical implementation to provide exactly this. = (Side note: only when Java got introspection in V1.2 or was it 1.4? it = became possible to port WO to Java). Let=E2=80=99s say your EO has a =E2=80=9Cname=E2=80=9D attribute which = you define in the EOModel. Any EO can be messaged and if it = =E2=80=9Cunderstands=E2=80=9D the message it will act. If an object = sends the =E2=80=9Cname=E2=80=9D message to an EO it will get the = contents of the name attribute back if the receiving EO understands this = message. It does when it has a =E2=80=9Cname=E2=80=9D attribute, it does = not otherwise. The same is true if an object sends the =E2=80=9CsetName=E2= =80=9D message. KVC implements different strategies to make this message passing = possible. It looks for direct access possibilities to attributes, it = looks for accessor methods and it plays with names for such attributes = and methods (name, _name, name(), getName(), etc). It tries hard to = overcome the limitations of the programming language to allow the = freedom of sending arbitrary messages to any object. This is also nicely visible for bindings in the wod or when specifying = key paths in code. In Java myObject.purchase().car().brand() will crash = with a NullPointerException when your purchase does not include a car = because you cannot call the brand-method on a null car object. The same = in KVC and bindings works: value =3D myObject.purchase.car.brand; Again = current programming languages do not support something like this and = depending on your code having accessor methods you might get NPEs = nevertheless because you make it so hard for KVC. Man do I love this stuff! It=E2=80=99s the purest implementation of OO = concepts I know of (other than probably Smalltalk). This is the main = reason why I use WO when teaching OO programming. I would have used = Smalltalk but it had to be a bit more modern language (heh heh heh - the = school said so). ---markus--- > Is this documented somewhere? Far as I can say, neither = ERXGenericRecord nor EOGenericRecord nor = NSKeyValueCoding.DefaultImplementation mentions anything special; = NSKeyValueCoding.DefaultImplementation.takeValueForKey should simply = check for the accessor (either with or without the _ prefix) and if = there is none (which there indeed is not), fall to = handleTakeValueForUnboundKey. What am I missing here? >=20 > Thanks, > OC >=20 >=20 >=20 > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > To switch to the DIGEST mode, E-mail to = > To switch to the INDEX mode, E-mail to = > Send administrative queries to = >=20 Markus Ruggiero rucotec GmbH web https://rucotec.ch Steinenvorstadt 79 email markus.ruggiero@rucotec.ch 4051 Basel / Switzerland mobile +41 79 508 4701 --Apple-Mail=_8B425D4F-0069-46A7-9B2D-65D1CA393A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = OC,

I will try to = answer your question from a conceptual angle...

On = 26 Aug 2021, at 03:50, ocs@ocs.cz <webobjects-dev@wocommunity.org> wrote:

Hi = there,

I must be missing something darn = obvious; looks like I've missed EOF 101 somehow :/


Nothing to = do with EOF. Well, not directly. See below...

My EO class, which extends ERXGenericRecord, does not = implement modelled property setters. Thus, I assumed takeValueForKey = would always fall through handleTakeValueForUnboundKey. Seems not.

I've overridden the methods like this:

=3D=3D=3D
class = OCSEnterpriseObject extends ERXGenericRecord {
=  static boolean canAccessFieldsDirectly { NO }
=  void takeValueForKey(value,String key) {
=    println "???takeValueForKey $key"
=    //super.takeValueForKey(value, key) // precisely same = behaviour as with the thing below, no difference
=    NSKeyValueCoding.DefaultImplementation.takeValueForKey(t= his,value,key)
 }
 void = handleTakeValueForUnboundKey(value,String key) {
=    println "???handleTakeValueForUnboundKey $key"
   // ... some stuff to simulate setter = (eventually using takeStoredValueForKey), not relevant, for it is never = called
 }
 ...
}
=3D=3D=3D

It does NOT work as = (I've na=C3=AFvely) presumed.


Your = presumption is wrong.

When = eo.takeValueForKey(o,key) is called, I can always see = =E2=80=9C???takeValueForKey=E2=80=9D (naturally), but I *never ever* see = =E2=80=9C???handleTakeValueForUnboundKey=E2=80=9C for any key amongst = modelled attributes. Nothing other (known to me) gets called =E2=80=94 = not even takeStoredValueForKey, which I've also overridden to log =E2=80=94= , but the value is set all right in the EO.

Only if foo is a random (non-existing, non-modelled) string, = I can see =E2=80=9C???handleTakeValueForUnboundKey=E2=80=9C.

Looks like there's some trick in = NSKeyValueCoding.DefaultImplementation.takeValueForKey which recognises = modelled attributes in EOGenericRecord and fill their values directly, = without falling to handleTakeValueForUnboundKey?!? Weird.


No, not weird, not at all.

Or I must be doing something very far wrong.


Ditto = no.

Your (and most other folks=E2=80=99= s) thinking of key value coding is wrong and way too technical. What = actually happens is the following:

Conceptually in object oriented programming = objects communicate with each other. This is a 2-fold process. One = object sends a message to another object and the receiving object then = acts on that message. This distinction is beautifully visible in = Objective-C where there are two syntaxes available. One, the classic C = call, relies on early binding. This is just a simple function call and = the called code is determined at compile time. The other syntax, the one = most programmers don=E2=80=99t like (because they don=E2=80=99t = understand it), is the [myObj myMessage] thing with the square brackets. = This is really message passing in the true sense of the OO paradigm. In = this sense you can send any message to any object, even to a = non-existing object, and you either get a reaction or you don=E2=80=99t = because the receiving object understands your message or is does not. = Did you ever wonder why in the WO docs the word =E2=80=9Creceiver=E2=80=9D= occurs so often?

Key value coding = in WO is a technical implementation of this mechanism. In =E2=80=9Cmodern=E2= =80=9D languages like Java one cannot send an arbitrary message to any = object - there is simply no syntax for it. KVC is the underlying = technical implementation to provide exactly this. (Side note: only when = Java got introspection in V1.2 or was it 1.4? it became possible to port = WO to Java).

Let=E2=80=99s say your = EO has a =E2=80=9Cname=E2=80=9D attribute which you define in the = EOModel. Any EO can be messaged and if it =E2=80=9Cunderstands=E2=80=9D = the message it will act. If an object sends the =E2=80=9Cname=E2=80=9D = message to an EO it will get the contents of the name attribute back if = the receiving EO understands this message. It does when it has a = =E2=80=9Cname=E2=80=9D attribute, it does not otherwise. The same is = true if an object sends the =E2=80=9CsetName=E2=80=9D = message.

KVC implements different = strategies to make this message passing possible. It looks for direct = access possibilities to attributes, it looks for accessor methods and it = plays with names for such attributes and methods (name, _name, name(), = getName(), etc). It tries hard to overcome the limitations of the = programming language to allow the freedom of sending arbitrary messages = to any object.

This is also nicely = visible for bindings in the wod or when specifying key paths in code. In = Java myObject.purchase().car().brand() will crash with a = NullPointerException when your purchase does not include a car because = you cannot call the brand-method on a null car object. The same in KVC = and bindings works: value =3D myObject.purchase.car.brand; Again current = programming languages do not support something like this and depending = on your code having accessor methods you might get NPEs nevertheless = because you make it so hard for KVC.

Man do I love this stuff! It=E2=80=99s the purest = implementation of OO concepts I know of (other than probably Smalltalk). = This is the main reason why I use WO when teaching OO programming. I = would have used Smalltalk but it had to be a bit more modern language = (heh heh heh - the school said so).

---markus---

Is this = documented somewhere? Far as I can say, neither ERXGenericRecord nor = EOGenericRecord nor NSKeyValueCoding.DefaultImplementation mentions = anything special; NSKeyValueCoding.DefaultImplementation.takeValueForKey = should simply check for the accessor (either with or without the _ = prefix) and if there is none (which there indeed is not), fall to = handleTakeValueForUnboundKey. What am I missing here?

Thanks,
OC



#############################################################This message is sent to you because you are subscribed = to
 the mailing list <webobjects-dev@wocommunity.org>.
To = unsubscribe, E-mail to: <webobjects-dev-off@wocommunity.org>
To = switch to the DIGEST mode, E-mail to <webobjects-dev-digest@wocommunity.org>
To = switch to the INDEX mode, E-mail to <webobjects-dev-index@wocommunity.org>
Send= administrative queries to  <webobjects-dev-request@wocommunity.org>



Markus = Ruggiero


rucotec GmbH              =           web https://rucotec.ch
Steinenvorstadt 79          =       email markus.ruggiero@rucotec.ch
4051 Basel / = Switzerland         mobile +41 79 508 4701








= --Apple-Mail=_8B425D4F-0069-46A7-9B2D-65D1CA393A7A-- --Apple-Mail=_E12A6E7E-618F-49A1-8535-D6B2CFA34B47 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCzkw ggUhMIIECaADAgECAhBDXz2PBS4rcSTMoUCPbeA+MA0GCSqGSIb3DQEBCwUAMIGWMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYD VQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUyMjAwMDAwMFoXDTIyMDUyMTIzNTk1 OVowKzEpMCcGCSqGSIb3DQEJARYabWFya3VzLnJ1Z2dpZXJvQHJ1Y290ZWMuY2gwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIAEK8S00IWrMmIpBkw5CcIS9RfaNGWyJOxskmtuYoHWE4 +QYfOO5tlWt4O5F6bTYsRWp1PpLirrdLhQoYIFp0P5Mi0nsBjNVP0zR0jNpDZreNcLcP7wmuIkUY C0fzxFgnRieFFgaXFm5yf46rqAJMVry/uR/KqwvY1d2F2gOb4DmntPp7TJtDsVyWQDtB82Uep+EO 9j71phQuMUb5TyA4aOdSb6UfCev1RgEw8vXrTdf+1rLzRZvIR1syfsqcLVmIO9WSl9mTH7IlZQhx SmTLqSTvTLssRGprVK8dhJl0nDvFuKknUGNxwCwON1ojJdZPgUJi1K+VvkCqDlI61czNAgMBAAGj ggHTMIIBzzAfBgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUFRQz2DQf fM2xz9tI/Gy05p6XXc0wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUH AgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwu c2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxD QS5jcmwwgYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNv bS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEabWFya3VzLnJ1Z2dp ZXJvQHJ1Y290ZWMuY2gwDQYJKoZIhvcNAQELBQADggEBACeso6Iombd/K2MXqk+u5cFNAi3kNRv5 t1WMA2YodqQxz/i/H9OxagG8Ukk5IcHgrikpy0dlOgJ9nOGEWJYrzZbLWZCMd7I8NQpT28vnkgKM 51tzAARg7mHu+SPKwvnDfYB8CFNSQ+Wlkq8wJHL9ALuTeGCRdnRmNtit8o/sRV25KoH6+0U2k08U TO5J+bzVendvcfygdf3bPp3+imRIlXJihwb2fg6OOMqVCnUFHKrdJULZ+SWSWNclriu5GbM1pKql d5dIrApf9M9b9XbY89XgHdFHA5bx7taL1Ie1msC23llmUVSYTHjNOqNrprgfKXvao1taAQvpDhzx BQXzO6YwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUAMIGIMQsw CQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAyjztlApB/975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXj So5MqXUfItMltrMaXqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQ PKA19xeWQcpGEGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ 79Khj1YBrf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se 3ed0PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0A MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYG CCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJU cnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjjsb0XMZHz tuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8zdMSgaDrkVYzz 1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk 2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI +jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO 2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3 a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEG VqR1hiuQOZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niF hsM47qodx/PL+5jR87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6m SWE3Bn7i5ZgtwCLXgAIe5W8mybM2JzGCA8QwggPAAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0 aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhBDXz2PBS4rcSTMoUCPbeA+MA0GCWCGSAFlAwQCAQUAoIIB6TAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA4MjgxNTAyNTVaMC8G CSqGSIb3DQEJBDEiBCBVmEdaQ8y1Yp3eMLFdLTBOXmvLh0gFbzvHBSA/+f+sSjCBvAYJKwYBBAGC NxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3Rp Z28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBDXz2PBS4r cSTMoUCPbeA+MIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBM aW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl Y3VyZSBFbWFpbCBDQQIQQ189jwUuK3EkzKFAj23gPjANBgkqhkiG9w0BAQsFAASCAQChaDH8176E hSBJ/wEMPiUOEOcwhO4CpXXCXrVvqrrujdoICBPqqAH8t7CL45Hd8L5rxMm0XesTVOl/V7Oi+YRK AnjaSBTs3bNyUGJ6Bc53mA0MmJJyI0oiVt+SaMuqPdx4CnF9HlzRZS5tz7prnHw6osj8etGAa/ME TFc2yrlF1RrLDwB5auruiWCpKVmCx5U+nFy2mmjTfBwDcvXp8aardgdn1ibuPB4atFNo7p2id5IY FVgZi3uvd7cisD3cxSpPxX2acIMJPA74GjRs+DOwS2LHxyJ3cpJigqMibxjubt7mEQWDULeTEiIQ MtcHgtL4jMUppUnT5AmNSWTSbQ3XAAAAAAAA --Apple-Mail=_E12A6E7E-618F-49A1-8535-D6B2CFA34B47--