Czy adnotacja może mieć lambdę ?

Czy adnotacja może mieć lambdę ? Jak by się to pisało ?
A gdyby miała, co by było kontekstem dla wywołania takiej lambdy ?
A metodę instancyjną (tzn normalną - nie statyczną), podaną nie jako string, a sprawdzaną przez kompilator ?

Dziwne pytanie?
Na propertisie/polu obiektu biznesowego wskazać że w pewnych kontekstach jest read/only (choć generalnie i na poziomie kompilatora jest r/w)

(Nie interesuje mnie rzucanie wyjątkiem z settera, owszem, tylko jako druga linia obrony, ale najpierw wczesna informacja)

Java 17.
Wersja Kotlinowska jest akceptowana

Zawsze możesz zrobić:

@Adnotacja("dowolny kod w javaskrypcie albo PHP")
void mojaMetoda() {
}

Do czego mnie zaprowadzi takie myślenie

@Retention(RetentionPolicy.RUNTIME)
@Target(value = {ElementType.FIELD, ElementType.METHOD})
public @interface ConditionalReadOnly {
//    String value();
    Class<? extends WhatToDerive> readOnlyDiscriminator();
}

Z czego musiał bym dziedziczyć, żeby było fajnie ?

ZrobieDobrze napisał(a):

Do czego mnie zaprowadzi takie myślenie

@Retention(RetentionPolicy.RUNTIME)
@Target(value = {ElementType.FIELD, ElementType.METHOD})
public @interface ConditionalReadOnly {
//    String value();
    Class<? extends WhatToDerive> readOnlyDiscriminator();
}

Z czego musiał bym dziedziczyć, żeby było fajnie ?

Jak dla mnie to to nie jest nic odkrywczego.

@ZrobieDobrze:

Na propertisie/polu obiektu biznesowego wskazać że w pewnych kontekstach jest read/only (choć generalnie i na poziomie kompilatora jest r/w)

Brzmi mocno podejrzanie. Czym są te "pewne konteksty" i czy są znane w czasie kompilacji czy runtime?

yarel napisał(a):

@ZrobieDobrze:

Na propertisie/polu obiektu biznesowego wskazać że w pewnych kontekstach jest read/only (choć generalnie i na poziomie kompilatora jest r/w)

Brzmi mocno podejrzanie. Czym są te "pewne konteksty" i czy są znane w czasie kompilacji czy runtime?

enum RodzajCenyNaWęgiel { ...};
enum RodzajOdbiorcy { OsFizyczna, Emeryt, WyborcaPewnejPartii ... };

class ZamówienieNaWęgiel { 

    @ConditionalReadOnly(zamówienie -> zamówienie.odbiorca==null || zamówienie.odbiorca.RodzajOdbiorcy==null) 
    RodzajCenyNaWęgiel setRodzajCeny();  
}

Może ustalmy, dla większosci z Was jest pewna oczywistość "zadzwoń do zespołu frontedowego, to ich broszka".

Dla mnie to największa patologia czasów backend-frontend. Nie będę dzwonił do frontendowca na każdego bąka, którego operatorka kserografu w ministerstwie przysasiniła przy pochyleniu się nad urządzeniem, zanim z dysgraficznym frontendowcem skutecznie wymienimy maile bez interpunkcji etc...

Celem jest posiadać wyraziste miejsce, gdzie takie reguły siedzą, encja biznesowa wydaje się najlepsza.
A czy przez DAO i REST fornman dostanie z danymi metadane, to tylko kwestia implementacyjna.
Bo o metadane (pewnego rodzaju, bardziej dynamiczne) chodzi

@ZrobieDobrze:

Póki co, problem wyobrażam sobie tak, że następuje strzał z frontu do jakiegoś backednowego endpointa. Następnie dane są deserializowane do jakiegoś ZamowienieDTO, które czasami ma odbiorca==null, a czasami coś innego - zależy od kontekstu (czyli de facto od interfejsu, do którego następuje strzał). I tu gdzieś wkraczają adnotacje, które mają rozwiązywać pewien problem, który nie do końca rozumiem. Jak te @ConditionalReadOnly miałyby działać?

1. Kto miały być konsumentem tego czy reguła odpaliła, czy nie ?
2. Co miałby robić z taką informacją?

Bez ConditionalReadOnly, wyobrażam sobie, że gdzieś następuje zamiana DTO na coś bardziej namacalnego typu ZamowienieDoAnulowania, ZamowienieDoWyszukania, które może nie mieć odbiorcy, ale ma nr zamówienia i to jest wystarczające do realizacji scenariusza biznesowego "Anuluj zamówienie", "Wyszukaj zamówienie", ale nie jest wystarczające do zarejestrowania NoweZamowienie (czyli DTO z odbiorca==null ma rację bytu jeśli przyszło przez /orders/status, ale nie ma racji bytu np. dla /orders/newOrder - URLe od czapy, więc nie skupiałbym się detalach).

Z ConditionalReadOnly mam wrażenie, że dla różnych caseów operujsz na Zamowienie, niezależnie od kontekstu i czasem to rodzi problemy.

yarel napisał(a):

@ZrobieDobrze:

Póki co, problem wyobrażam sobie tak, że następuje strzał z frontu do jakiegoś backednowego endpointa. Następnie dane są deserializowane do jakiegoś ZamowienieDTO, które czasami ma odbiorca==null, a czasami coś innego - zależy od kontekstu (czyli de facto od interfejsu, do którego następuje strzał). I tu gdzieś wkraczają adnotacje, które mają rozwiązywać pewien problem, który nie do końca rozumiem. Jak te @ConditionalReadOnly miałyby działać?

1. Kto miały być konsumentem tego czy reguła odpaliła, czy nie ?
2. Co miałby robić z taką informacją?

1. GUI, 2) Choćby wyszarzyć kontrolki (bo pierdyknąc wyjatkiem po powrocie nieprawidłowych danych to z deka za późno)
   Oczywiście, z góry tzreba założyć, że protokołem ganiają nie tylko dane, ale i metadane

Bez ConditionalReadOnly, wyobrażam sobie, że gdzieś następuje zamiana DTO na coś bardziej namacalnego typu ZamowienieDoAnulowania, ZamowienieDoWyszukania,

Zamówienie na wągiel to przykład (medialny, he he). Umowa o pracę -> 60 klas zrobić?

Z ConditionalReadOnly mam wrażenie, że dla różnych caseów operujsz na Zamowienie, niezależnie od kontekstu i czasem to rodzi problemy.

Umowa o pracę, lepiej ?

Teoretycznie można to zrobić.
Tworzysz własną adnotację.
Wpisujesz w nią coś na zasadzie @MyAnnotation("System.out.println(\"I'm a freak\"")
Piszesz plugin do kompilatora, który to wyciągnie do jakiegoś osobnego pliku .java i jakoś tam podłączy.

Albo nawet runtime wyciągnąć stringa, skompilować, dodać do classpath i uruchomić.