What challenges could a semantic framework face?

This question has a bit to do with unit testing. For those who may have used it, you’d observe they have mocks and stubs that imitate an SUT’s method calls with methods like expects, when, assert etc. So I’m asking to know If there was a package that enabled implementing logic itself with those high level calls, what challenges could such package face? I mean in a codebase or framework where the dev calls methods like expects, when and co, instead of low level constructs like if statements, writing full blown logic etc.

Not really sure I understand the question. Are you looking for something like Mockery or Prophecy?

No. Those addons you mentioned are merely for testing proper. They have methods like expects, when etc. I’m asking this: assume there was a framework that allows you implement your application’s business logic using such high level methods (as opposed to manually fleshing out logic, composing methods and connecting dots for the feature behaviour), what challenge could such a framework face?

I’m not sure how such a framework would look like. The thing about mocks, spies, etc is that they always implement partial behaviour. Given A, expect B. But given C it doesn’t have a clue, because nobody ever told it to expect C.

So basically you’d still need to specify everything if it is to serve as an actual implementation. At that point I think the high level setup only gives overhead, no gain.

If you could somehow make those problems disappear than I think the greatest challenge a framework like this would face is that becomes over-opinionated in how problems should be solved and instead of becoming a generic framework it would quickly become a very specific one.

1 Like

Yes, yes, yes! You’re absolutely correct for the most part of your response.

I realized what I’m trying to describe is abstract and was in the process of whipping up an illustration with a real world example when your reply came in.

Assume you have an online store where buyers awarded coupons can apply their bonuses during checkout. Also assume $framework refers to the imaginary platform being discussed in this context.
Your hypothetical buyer enters the coupon in a field just before checking out, and the following code ensues

<?php

	public function paypalTakeoff(array $paymentData) {

		$payment = new Payment($paymentData);

		$framework->when($payment)
		->has(Bonus::class)
		->validate( Bonus::getValidationRules()  )

		->then($payment->setNewPrice)
		->catch(header('Location: /error?reason=invalid-Bonus'));

		$framework->assert(
			Products::find($paymentData['product_id'])->price,
			$paymentData['price']
		)

		->then(PayPal::redirect($paymentData))
		->catch(header('Location: /error?reason=fraudulent-Buyer'));
	}

	public function paypalCallback(array $paypalPayload) {

		$user = getCurrentUser(); // from session, or what have you

		$framework->createMany(Products::class, $paypalPayload)
		->assignTo($user)->as( Orders::class) // internally holds a list of products linked in the ORM to both user and order

		->update(['bought' => 1]);
	}
?>

Of course, with every level of abstraction in software comes overhead and potential loss in performance. The aim here is development time and an overview approach toward writing software. I intentionally left out comments from the code above to see how easy it is for an outsider to grok what it does by mere looking at it

I agree with this. But isn’t this one of the aims of writing frameworks – tailoring programs to a certain paradigm? You have a framework looking in specific places for specific things, in specific formats, configurations etc

Would love to hear your thoughts on the code above and how it could be adapted to something entirely different (like a fin-tech or music streaming feature) given the methods.

I think another way to put it is: Developers are presented with user stories across different domains and approach their implementation in various ways (but really perform the same logic underneath). This parallels unit testing because we have the testing framework that is capable of accepting SUTs from any domain, and performing those generic actions on it. So, what happens when we have a logic framework capable of accepting any domain and performing generic actions on it?

I’m afraid I’m missing the point. It looks just like normal code except that you’ve replaced the usual keywords with some fluid interface in a framework. You could kind of create the same effect by using intelligent methods on the objects you’re passing around.

Kind of sounds like you’re looking to implement a Domain Specific Language (DSL) though. Maybe that term can aid in your search?

:woman_facepalming:t4::woman_facepalming:t4:
I don’t know what “normal code” means to you. The aim, like I said, is to limit developer interaction to designing domain specific models. The framework itself will be general purpose.

That code I posted above, in the codebase at my workplace, takes up no less than 350 lines of logic. Now, I’m imagining if 10 other devs implementing something similar could do it in those same 30 or so lines. In the same vein, somebody implementing categorization on a farm produce app can decide to use (from my sample code) has,when,createMany,update where appropriate. Achieving this without fleshing out the whole logic from ground up.
There are no DSL constraints in the code I posted. Aside the models being plugged in, there’s no indication that the framework is tailored to a coupon e commerce checkout. I don’t know how else to explain what I’m driving at, but I feel I’m beginning to sound like a broken record. It’s alright if I’m unable to convey my idea or request in more lucid terms. Many thanks for stopping by

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.